EP1904925A1 - Processing system - Google PatentsProcessing system
- Publication number
- EP1904925A1 EP1904925A1 EP20060726597 EP06726597A EP1904925A1 EP 1904925 A1 EP1904925 A1 EP 1904925A1 EP 20060726597 EP20060726597 EP 20060726597 EP 06726597 A EP06726597 A EP 06726597A EP 1904925 A1 EP1904925 A1 EP 1904925A1
- Grant status
- Patent type
- Prior art keywords
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- G06—COMPUTING; CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5066—Algorithms for mapping a plurality of inter-dependent sub-tasks onto a plurality of physical CPUs
This invention is concerned with a processing system, and more specifically a system, the various parts of which are provided to manage computer processor intensive tasks in a reliable, robust, scalable and efficient manner. Yet further specifically, the invention is concerned with the management and control of multiple user requests (including the possibility of many users making single requests, and one or only a few users making multiple requests) for computer processing power, the results of which produce one or more computer files which are to be returned to the user by predetermined means.
Although the following description is almost exclusively concerned with a processing system for managing and controlling multiple user requests for image rendering tasks, it will be understood by those skilled in the art that the system hereinafter described may apply equally to other computer processor intensive tasks, such as database rationalisation, numerical analysis (such as finite element analysis), and data manipulation in general. Indeed, the system hereinafter described may be used in a wide variety of applications in which there is a requirement to manage, control and distribute processor-intensive processing tasks in a reliable, effective, efficient, and scalable manner.
Computer image rendering has long been known to be a highly computer processor intensive, and indeed computer memory-hungry task, both in terms of physical disk space required (computer files describing high resolution images are often of the order of many megabytes or MB), and in terms of the RAM into which such image files must be loaded before any alterations or modifications to those images can be carried out in the software from which they were originated.
There are already in existence a wide variety of computer programs for creating, altering, and manipulating images, in both two and three dimensions. At the time of filing of this application, it is probably the case that the use of computer-aided design tools, software and product prototyping is fairly ubiquitous across all manufacturing industries, not least because the computer and the relevant software loaded thereon is capable of providing an exceptionally detailed spatial visualisation of the product being developed. The on-screen image of the product can thus be viewed on screen by any user having the same or compatible software to that in which the file was created or from which it originated. Furthermore, with compatible computer-aided manufacturing equipment, it has become possible in recent years to manufacture products using the original computer files, and this has allowed for huge increases in manufacturing productivity.
The advertising industry is fundamentally concerned with the display of products, their packaging and any associated artwork, brand, logos and the like in a- manner which catches the public eye, or at least alerts the attention of the public to the existence of those products. The reader will instantly appreciate that there is a myriad of different advertising techniques, the majority of which use various different media to achieve its aims. Of most relevance to this application is the use of printed media to advertise products, because currently and for the foreseeable future, anything which is to be printed on practically any media will originate from a computer loaded with industry-standard software packages, such as Adobe® Photoshop (traditionally used for the generation of very detailed computer images, artwork, textures, layers and the like) and 3D Studio Max™ (which is traditionally used for the creation of 3D images, models, and animations and the like). While this application focuses predominantly on printed media, it is to be mentioned that the system hereinafter described is capable of producing images in various formats or file types-e.g. TIF files are commonly used in print, PNG files are useful in web development, and JPG or JPEGs are good for general distribution. Accordingly, images produces in these formats can be used for print, web, multimedia, screen and broadcast applications.
In a conventional situation, it is known in the advertising industry to model a three dimensional product or article in a modelling package such as 3D Studio Max. It is important for the purposes of this invention that the modelling package uses a polygonal and/or parametric modelling algorithm or technique so that any changes to the size of the article in terms of on-screen size (and the actual physical size of the article represented in the software) are mathematically calculated to ensure that the enlarged article bears as exact and identical a resemblance to the initial model as is possible.
Thereafter, the graphic artist will generally turn to an image creation and manipulation software package, such as Adobe Photoshop, to either create or manipulate a pre-existing artwork or texture file. In the case of a simple product container such as a tin or beverage can, the artwork files may be relatively simple containing only text, logos, relatively few colours and/or complex images, whereas in the case of a complex product, such as a shoe, the artwork will be complex in both content and shape, and will be more akin to a "texture" as opposed to simple artwork. For example, a model of a tin might comprise a single artwork file (the label, which contains text, logos, images and colour), and might also include various maps (textures) created by the artist to simulate attributes such as reflections and relief textures.
In any event, it is common practice in the field of image creation and rendering to firstly model the particular product or article shape in a 3D package, and then to create an artwork or texture file (typically a vector-based artwork file) for application and combination with the 3D file. In cases where artwork is supplied, artwork may be a vector/raster hybrid converted into raster. Typically, this format is non-scaleable, but is originated, applied, and stored at a high resolution of detail that can be drawn upon and is mostly used at a much lower quality than the source.
At this stage, there is no specification by the user as to the eventual physical size of the image which is required to be printed, its required print resolution, or the type of file which is ultimately required. These parameters are specified immediately prior to a rendering process. Accordingly, at this stage in the process, it is possible to vary the 3D model to any desired size without any loss in ultimate image quality. The reason for this is the fact that the 3D model is polygonally and/or parametrically (and thus mathematically) defined. The artwork is described in a vector or vector/raster hybrid format (also a mathematical definition), and therefore cannot be scaled past its original size without loss in quality, but in general the quality provided in such files (and certainly as far as this application is concerned) is far in excess of that ultimately required by a user. Importantly though, any resizing of either article model or artwork is mathematically calculated as opposed to being simply scaled according to the resizing request. In this regard, it is also to be mentioned that the term "re-size" and its cognate expressions can be taken to include the alternate construction whereby the virtual "camera" through which the user is viewing the model and artwork on-screen is re-positioned so that the model appears larger or smaller. Ultimately the effect achieved is the same.
Once a user has these two essentially mathematical descriptions of on the one hand a 3D product or article, and on the other hand artwork intended to be applied integrally with or to the surface of that article, a rendering process can be undergone whereby the artwork file is virtually "applied" to or connected with the 3D product model so as to become part thereof, and the re-sizing and image resolution parameters can be chosen prior to the carrying out of the process. The rendering process is highly processor intensive because during the creation of the final rendered image, an enormous number of mathematical calculations are required to be carried out as both the polygonal-based article model file and the image/artwork file are resized and combined to provide the final rendered image at the required size (i.e. physical x, y dimensions) and the required resolution (usually specified in d.p.i. or dots per inch). Typically, it is worth mentioning that the image/artwork file may be initially provided as a combination of vector and raster-based elements which may subsequently be finalised into a full raster image at as high a resolution and quality as possible.
The rendering process has long been known to be a very resource-hungry processing technique, and is often used in benchmarking tests for processors to test their speed.
The demands on processor and memory resources can be further understood when during a rendering process, the colour of the pixel, which might depend on its native colour, its texture, reflection, glossiness, the amount of light and shadow it is receiving, the amount of shadow that is cast upon it etc., must be calculated for every single pixel in an image. This process may have to be repeated hundreds of thousands and possibly millions of times per image.
In commercial image processing and manipulation environments, normal practice has been to provide graphic artists with computers having exceptionally highly specifications to ensure that any image rendering which is required to be done by them can be carried out on a local basis at their own computers without either causing interruption to their office computer system in general and without talcing too much time on that computer-it is worth mentioning that during more complex image rendering processes, it is common for the computer processor (at least that in a personal computer anyway) to be entirely utilised so that the effectiveness of the computer in carrying out any other task is dramatically and drastically reduced and it becomes ultimately useless while the rendering is taking place.
The fundamental difficulty, at least as far as this application is concerned, is that while in the vast majority of circumstances, it is acceptable for image rendering to be carried out on local, albeit highly specified PCs, this system cannot work for a multiuser system where either a large number of users wish to make image rendering requests, or a relatively few number of users wish to make a large number of different image rendering requests, based on 3D product/article models and associated artwork files which might be centrally stored, e.g. on a computer server. Additionally, the local processing model precludes the receipt of remote processing requests, for example over a WAN.
The applicants therefore have determined that it would be incredibly beneficial, and it is an object of this invention, to provide a system whereby multiple users could make multiple image rendering requests and be later notified that their requests had been completed, whereby the user might then take some further action to retrieve the rendered image files.
The fundamental difficulty with providing such a system is the need to have some means of controlling how the processor of one or more machines operates. The reader may be aware of the "SETI@home" project which is currently in existence and widely known within the scientific research and IT communities, and which is embodied in a small downloadable program which individual PC users can install on their local machines to allow their machines to be integrated into a distributed computing network.
Briefly, this program allows the particular PC on which it is loaded to communicate with the SETI@home management program which in turn retrieves processed data or delivers unprocessed data to that PC for processing. The reason for the existence of this project is that "SETI" or the "Search for Extra-terrestrial intelligence" involves monitoring the radio-frequency spectrum of the cosmos digitally and processing the results of each and every measurement taken. This requires the processing of such a vast amount of data that no single computer has yet been built which can carry out the job, and hence the concept of distributed computing used, whereby individuals having only relatively small amounts of spare processing power devoted their computers to analysing only tiny fragments of the data, and then returning this data to the SETI management program for depositing in a database.
Distributed, grid or cluster computing (such as the SETI@home project) is not new, and there already exist a number of different mechanisms by which this might be carried out, but the present invention is distinguished from such systems as will become apparent from the below.
The above is provided as an example of distributed computing where it is possible to easily divide the enormous processing task into numerous (indeed maybe millions or even billions) of smaller tasks and to distribute these to individual PCs for processing. In the case of image rendering, this is much less easy to achieve (although it can and has already been done). Those in commercial image rendering houses will already be aware of the difficulties of providing production level image rendering wherein a number of successive image rendering requests are sent to a single computer (usually a server or other high-end machine) without allowing significant time between each request. It is well known that placing too high a demand on any computer can easily cause it to fail by crashing, and image rendering is no exception.
It is an object of the invention to provide a system for controlling, distributing, returning and retrieving information about computer processor-intensive tasks conducted on one or more computers having processing capability, and specifically providing a management tool for achieving this.
It is a further object of the invention to provide a universal application and server information translation tool for monitoring, controlling, distributing and retrieving both processor-intensive tasks, in particular (though not exclusively) image rendering, and for providing information about the status of such tasks.
According to the present invention there is provided a computer processor intensive task management system including a front end element in the form of a graphical user interface to receive user input in the form of task parameters, a webserver element which contains all the various sections of the specific graphical user interface for display and through which user input is made during the task parametrization procedure, said webserver element being capable of dealing with a plurality of client requests to display said graphical user interface on a plurality of separate clients and also dealing with a plurality of user inputs received from each of said clients; a middleware element which communicates with the webserver element and receives task parameters for each and every task requested by user, said middleware element further communicating with a back end element comprising processing power in the form of one or more clusters of one or more computers having processing power for conducting the processor- intensive tasks requested, and a storage element where the results of conducting the processor intensive tasks may be stored, wherein the middleware element includes a queue function, a calculation function, a memory function, and a task distribution function, said queue function being used to hold details of all the tasks requested by the webserver, including the various parameters specifying those tasks, said calculation function being used to determine the likely amount of processor time involved in completing the particular task requested based on the task parameters received by said middleware element for that task, said memory element being used to contain details of previously distributed tasks and the particular clusters to which they were sent, said distribution function being used to successively and intermittently distribute tasks within the queue, and wherein the distribution of the tasks in the queue by the middleware element is made dependent on their determined completion time and also takes into account the predicted processor activity of clusters in the back end element to which previous tasks have already been sent.
It is preferable that the middleware element further comprises a division function which is capable of subdividing each requested task into smaller tasks each of which then occupies a position in the queue as would conventional non sub-divided tasks and may be prioritised and distributed accordingly.
Preferably the queue element may be made up of both subdivided task portions and whole tasks, and the distribution of either to the back end element is still managed by the middleware element according to the determination of likely processing time. Most preferably the webserver communicates with the storage element to retrieve details of completed tasks for display to users at clients of said webserver. Most preferably the particular tasks are image rendering tasks, in which case the system further includes a database element containing details of each 3d article model and artwork adapted for that article, said back end element communicating with the database element to retrieve the relevant 3d article model file and artwork file for that article as a first step in the image rendering process, secondly rendering those two files according to the particular parameters given for that particular image rendering task, and thirdly returning the rendered file to the storage element for later collection by the user.
Most preferably, where the tasks are image rendering tasks, the storage element also includes small 3D images, based on the actual 3d article model file and associated artwork file but reduced in resolution and size for display on a simple web-front end, and which can be selectively rotated about a variety of different axes, so that the user can choose in the graphical user interface which particular orientation of the image he wishes to have rendered by the system.
Those skilled in the art will be aware that web-based plug-ins are available which allow this functionality, the most notable being Shockwave® produced by Macromedia®.
As an example, a web browser with such a plug-in installed can accept a suitable, compatible image of a product have artwork pre-applied thereto, and using particular buttons of a mouse, can accurately and precisely control the angular orientation of the article being displayed in the browser. [Currently, it is to be noted that a very similar effect can be seen for mobile phones at www.nokia.com. In this display, the orientation of the mobile phone can be changed on screen so that any user can see all sides of the phone in view.] It is preferable that in addition to this facility for viewing a digitised image of the article in any particular desired orientation, the graphical user interface (GUI) also includes provision for entering angular orientation parameters (as well as other parameters such as physical image size, resolution, quality etc.) manually through a keyboard.
Most preferably, the GUI allows for a user to select from a number of predefined parameters.
Examples of the types of processor intensive tasks to which the system of the invention might be ideally suited are 3D image rendering, scientific simulation, very large data warehouse systems, and any task which requires a large quantity of processing power or highly scalable multiple instances of lesser processing power.
As described above, the middleware consists of a set of applications which allow the users to utilize the power of large distributed computer networks (e.g. cluster/grid), for software that would not usually have access to this type of processing power. Effectively it acts as a translator between the client and the back end element.
Preferably, the middleware element is non-hardware or software specific in that it can handle various configurations of distributed/clustered server systems hardware, and can work with whatever configuration is needed to provide the optimum throughput and stability for any given task processing requirement.
As a result of this invention, and in particular the middleware element thereof, multiple clients can utilize any number of server rendering options and maintain a consistent throughput and level of performance, eliminating bottlenecks and data bandwidth issues associated with single server systems.
This makes the middleware a very flexible and dynamic piece of software, cutting down on the re-development time and cost of creating bespoke software every time a different type of server based renderer was needed. This also can be scaled up, almost indefinitely, providing more processing power, as demand grows.
The middleware provided hereby can add extra functionality and stability to off the shelf products, and is able to bring them into an automated enterprise class environment. For example, proprietary software such as 'BackBurner' by 'discreet', which is capable of linking in to 3D Studio Max for distributed network rendering, but the applicants herefor found that the "backburner" software regularly failed by crashing the server when only a relatively few number of image rendering requests were made of it from 3D Studio Max. Middleware had to be created to provide the utilities and procedures required for a commercial, enterprise scalable, online (i.e. using web front end) rendering service.
According to a further aspect of the invention, there is also provided an image rendering service including all the elements of the system mentioned above.
Most preferably the middleware element is capable of communicating with the various other elements of the system to retrieve and return relevant process information from and to said system elements.
Unlike existing proprietary software, the middleware described herein can process multiple users and multiple unique and non-unique image rendering requests simultaneously. Furthermore, it achieves this without producing errors or crashing, and most preferably this is achieved by assigning a unique ID to each task request it receives (or first sub-dividing the particular tasks, assigning unique IDs to each of these tasks and then re-combining the tasks post processing) and communicates with the database element to ensure that the correct information and procedures are being performed for the correct user. Further preferably, the middleware element includes a time stamp facility for each task or subdivided task so that they can be processed and released to the user within specific time thresholds.
It is worth mentioning that proprietary software will release image rendering jobs only when a render node is available and would not be able to add unique delays or settings, if required, and as can be achieved hereby.
Also, not only does the middleware element access a database for article model and artwork information and files, said database element can also include other less task specific information such as user accounts, angle data and product hits, render times and system performance. During the complete cycle of an image render, the middleware element will have handled and logged all associated data, which is used for maintenance, future system development, and marketing etc. The nature, amount, and diversity of this data cannot be produced using existing proprietary software.
The middleware element is also designed to accommodate different rendering platforms and acts as a multilingual translator. Existing proprietary software will process jobs using its native language and rendering platform only.
A yet further aspect of the middleware application is that commercial and industrial deployment considerations, such as account handling, billing and order tracking may be easily dealt with. Furthermore, the middleware element provides a means whereby requests from remote users with no knowledge of the particular system employed by the invention can be received and processed apparently effortlessly without any requirement on the part of the user to understand how grid or distributed computing actually operates.
A specific embodiment of the invention will now be described with reference to the following figure. It should be noted that this specific embodiment is provided by way of example only, and a skilled reader will understand from the foregoing that the invention may easily be applied to other processor intensive applications..
Figure IA provides a schematic overview of the system according to the invention,
Figure IB provides a schematic indication of the proprietory work involved prior to the carrying out of processor intensive imaging rendering tasks by the system according to the invention,
Figure 2 shows a schematic of the system according to the present invention , and
Figure 3 shows a schematic flow chart providing a simplistic representation of the process also according to the present invention.
Referring firstly to Figure IA, there is shown a user/client "front end" 2 A segregated virtually by dotted line 3 A which communicates over the internet with a webserver element 4A (which might be incorporated as part of the overall middleware element of the invention, but is more likely to be separate therefrom) which in turn communicates with a middleware element 6 A. Said middleware element comprises a master application server 8 A, a master database 1OA, and a master storage component 12 A. The master application server 8 A is typically employed as a process scheduler, a render resource manager, a product updater, and/or an image processer/archiver. The master database 1OA contains information such as product data, user data, server data, and financial data, whereas the master storage 12A may contain master 3D article files, master artwork files, output files and proxy models.
Said middleware element 6A may be accessed remotely, again over the internet, LAN, WAN or similar, by a production controller 14 A, system analyst, or article and/or artwork modeller who might upload new article files and artwork files into the middleware element 6 A, which is additionally bounded in the Figure by dotted line 16 A. The final components in the system overview Figure are the one or more render clusters 18 A, 2OA, 22A. In accordance with the invention, the middleware element communicates with these render clusters which perform the processor intensive tasks before returning the resulting images back to the middleware for storage and/or ultimate return to the user/client.
Although it will be clear from the following that certain configurations and functional elements of the middleware element are possible, the schematic Figure of IA makes clear that the middleware element might contain at least a storage and database element together with an application server element. Optionally, the middleware element might also include the webserver element.
It is also to be mentioned that the application server element of the middleware might additionally conduct one or more of the following functions:
Post processing of images;
Multi-frame image storage (to embrace animation);
Resource management of the system at large; Cluster node monitoring;
Software Update propagation through system.
Additionally, it is envisaged that an email notification/management engine might be included in the middleware element for issuing automatic notification to clients/users when their processing requests are completed. Also, the middleware might automatically upload completed/processed image files directly to clients'/customers' servers using FTP (file transmission protocol).
Referring now to Figure IB, and in particular Sections (a) and (b) thereof, the preparatory process steps for creating both suitable art work and/or textures files, and
3D model files are shown. Specifically, as far as creating art work or textures files is concerned, there are four potential means by which an art work or texture file may be originated, namely by taking a scan from existing art work, 2, using digital photography, 4, using existing digital artwork, 6, or creating an art work file from scratch, 8. In the case of pre-existing art work (2, 4, 6) additional preparation and image manipulation will be required, 10, before a finished texture or art work file 12 can be provided.
Referring now to Section (b) of Figure 1, it is a pre-requisit of the invention that a detailed 3D model in digital form be provided in conjunction with the relevant art work or texture file 12, and in this regard either a 3 dimensional scan may be made of the article to be modelled, 14, and existed computer aided design (CAD) file may be used, 16, or a 3D model digital file may originated in a suitable software package such as 3D studio max, as indicated at 18. (Of course, it is envisaged that the application of artwork to article files may be automated to a certain extent; e.g. once a standard tin shape has been produced by a modeller, large numbers of variants of artwork files can be produced by bespoke computer automation resulting in multiple types of tin, each with their own artwork).
In a case of pre-existing model files, further preparation will be required as indicated at 20 before a completed high resolution geometry file of the article which is being modelled is generated, 22. At this stage, the finished art work or texture file 12 may be applied to the high resolution geometry model file as generally indicated at 24, whereafter a completed high resolution model' including both geometry and artwork and/or textures is provided, 26. (It is to be mentioned that this file can be simplified to create a low-resolution counterpart file).
In accordance with the invention, this completed digital high resolution file is then stored in a suitable location, most probably on a storage element of the system
(herein after described) as indicated at 28, and as a final step a database element of the system is then updated with the relevant particulars of the completed high resolution digital file containing both the geometrical model and combined or associated artwork or textures, as indicated generally at 30.
The reader will also understand from the above description of the system that a low resolution model including associated artwork is required for display on the front end user interface to provide users of the system with a virtual image of the article and applied artwork which can be angularly orientated as desired by the user in the front end interface, but which nevertheless does not represent a significant band width limitation on the flow of information to and from the user, ie such files must be relatively small. In this regard, the various process steps for high resolution model rendering as previously described are generally the same, and corresponding reference numerals suffixed with an A are used in the second part of section (b) of Figure 1. As can be seen at 26A, the various prior process steps result in a completed low resolution model digital file which includes the geometrical article shape which has been modelled together with combined artwork and/or textures from the process described in section (a) of Figure 1. Once this digital file is in existence, it can then be exported as shown at 32, its resources are then stored for future reference at 34, and the relevant database element of the system is updated at 36.
Referring now to Figure 2, the various components and overview operation of the system according to the invention are described.
The system includes various hardware and software elements including firstly a client PC40 networked in someway either by being connected to the internet, and intranet, LAN or WLAN as indicated at 42. The client is indicated at 40 and provides a means by which a user 44 may interact with and/or control the system as a whole. The client communicates with a web server element 46 which includes a hardware element of a webserver 48 capable of servicing multiple client requests along communication channels 42 (of which there may be many 10s, 100s, or possibly even 1000s) and it is the web servers task to provide all the HTML, XML or other format files which may be displayed on the client computer 40, dependent on requests made thereby. The webserver element 46 also includes a database 50 with which the webserver communicates to access the low resolution models 26a created in the modelling process for display on the client computer 40. The webserver 48, as will be understood by the skilled reader is common practice, also receives the various parameters for each image rendering request made by the user in the form of user input 52, and it is this user input which characterises each image rendering request made by the user. This information is then passed to a middleware element 54 which is responsible for the core management of the image rendering server cluster 56 and its ultimate output 58 in the form of rendered digital image files which are stored in a suitable storage element 60 to which the webserver element 46 may optionally have access and be able to communicate therewith as indicated at 62. The image rendering server cluster 56 and/or the middleware element 54 can communicate with a database element 64 through communication channels 66, 68 respectively, and it is within this database element that various critical pieces of information, not to mention the original artwork and/or texture files, and 3D article models may be stored.
In accordance with the invention, the middleware element 54 comprises a variety of different functions schematically indicated at 72, 76, and these may include a queue function 70, a calculation function 72, a memory function 74, and a task distribution function 78. There may also optionally be provided a division function 78.
Referring now to Figure 3 in which the operation of the system is described, the overall purpose of the system as a whole is to enable users to view a large number of generally low resolution article model files on screen having relevant art work and/or textures applied thereto and to orientate such models on screen using both keyboard and mouse (not shown), and to select various parameters for a render process to be conducted by the backend element of the system (basically consisting of the render server cluster 56). Such parameters will typically be the final size of the rendered image, and its resolution, but there may obviously be other parameters depending on the complexity of the user interface. It is worth mentioning that the system according to the invention can provide a number of different file types (e.g., .png, .jpg and .tif) that are to be extended, so that the user can choose from web ready images (png), distribution ready images (jpg) and print ready images (tif).
Accordingly, once the user has chosen the particular image on screen, its orientation, and provided the various image rendering parameters required by the user interface provided on the client 40, a request is then sent to the webserver to begin the image rendering process of the particular image selected according to the various parameters given. At this stage, the webserver element then communicates with the middleware element of the system passing all the relevant information in terms of the parameters and particular article thereto, and at this stage the middleware element then begins the process of determining the likely time taken to complete the image rendering request, and to prioritise and/or subdivide this particular image rendering task according to a variety of different factors including the number of requests already having been made of the render server cluster, the urgency of the particular task, the relative state of completion of previously made image rendering requests as determined from the queue function, and a variety of other different variables. Accordingly it is to be understood that the middleware forms the overriding control colonel of the system in terms of both managing the tasks submitted to it and thence to the back end render server cluster 56, and in distributing those tasks either to particular processing units within the render server cluster 56 (marked as A, 1, 2, 3, 4, 5, 6) or indeed further (not shown) render server clusters with which the middleware element 54 may communicate. Once the middleware element 54 has made all the relevant calculations and determinations as to priority, urgency etc, it then submits instructions to the back end element of the system, or a particular hardware processing element thereof, and this in turn retrieves the relevant high resolution 3D geometric models, and the high resolutions artwork and/or texture files from the database element 64 and commences the processing task. Once the processing, ie the image rendering task is completed by the render server cluster or a particular element thereof, the completed and rendered image file is sent to the storage element 60, and a communication is initiated between the render server cluster 56 and the middleware element 54 to indicate to said middleware element 54 that the particular task is completed. At this stage, the middleware element 54 will communicate with the webserver element 46 to provide an indication that a particular user requested image rendering task is complete and further to provide an indication of the storage location where the completed rendered file may be retrieved from (a particular location on the storage element 60).
As all users of the system will be identifiable by their user name or other unique identifier, and information regarding that user will be stored as profile information in the database element 64, when that particular user logs back on to the client machine after the completion of a previously requested image rendering task, the user will be notified through the graphical user interface provided on the client by the webserver, and thereafter the user will be able to request that the completed rendered file be downloaded for subsequent use.
In terms of the particular step identified in the flow chart provided in Figure 3, the above system can be specified by the provision of an essentially public website 80 to which a user 44 has access. That public website 80 receives user input 82, firstly in terms of a user log in 84, such information being queried at 86 against the database record for that particular user indicated generally at 88, and if the log in credentials are correct then the user is permitted to access the first page of the graphical user interface supplied by the webserver to allow image rendering requests of the various articles held in the database to be made. This part of the process is generally indicated in Figure 3 at 90.
At this stage, the interface then receives further user input 92 and in the further various interactions between the web based interface provided on the client by the webserver and the user, indicated generally at 94, the user will provide a variety of different information to both select a desired article or product shown on the interface, provide various image rendering parameters connected to a desired image rendering task for the particular article chosen, and all the various pieces of information which forms part of the overall user input will then be submitted through the webserver and will ultimately reside in the database element of the system. The final part of the total user input will involve the submission of the request for image rendering to be completed, and at this stage, the webserver will communicate with the middleware element, as generally indicated at 96 in Figure 3, and at this stage the middleware element will then manage the process of image rendering by the render server cluster as previously described, and as schematically flow charted in Figure 3 at 98.
The final stage in the process is the completion of particular image rendering tasks by the render server cluster, and the return of the image rendered digital files to the user through the system, and this particular part of the process is schematically flow charted in Figure 3 at 100.
It is important to note that the webserver element 46, and in particular the webserver 48, together with the middleware element 50 (which is envisaged as a software only element, but need not necessarily be so) are both capable of communicating either directly or indirectly with the database element 64 in which all the details of particular image rendering tasks and the particular users requesting those tasks is stored. In Figure 2, the communication between the webserver element 46 and the database element 64 is shown as being indirect though the middleware element 54, but this need not necessarily be the case, and the webserver 48 may communicate directly with the database element 64.
In summary therefore, a computer processor intensive task management system is described. The system includes a front end element in the form of a graphical user interface to receive user input in the form of task parameters, a webserver element to contains all the various sections of the specific graphical user interface for display and through which user input is made during the task parametrization procedure, a middleware element which communicates with the webserver element and receives task parameters for each and every task requested by user, and a back-end element comprising processing power. The system also includes a storage element which may optionally be integrated with the middleware element or separate therefrom.
Priority Applications (2)
|Application Number||Priority Date||Filing Date||Title|
|GB0506337A GB0506337D0 (en)||2005-03-30||2005-03-30||Processing system|
|PCT/GB2006/001191 WO2006103460A1 (en)||2005-03-30||2006-03-30||Processing system|
|Publication Number||Publication Date|
|EP1904925A1 true true EP1904925A1 (en)||2008-04-02|
Family Applications (1)
|Application Number||Title||Priority Date||Filing Date|
|EP20060726597 Withdrawn EP1904925A1 (en)||2005-03-30||2006-03-30||Processing system|
Country Status (4)
|EP (1)||EP1904925A1 (en)|
|CA (1)||CA2603369A1 (en)|
|GB (1)||GB0506337D0 (en)|
|WO (1)||WO2006103460A1 (en)|
Cited By (1)
|Publication number||Priority date||Publication date||Assignee||Title|
|CN103679392B (en) *||2013-12-26||2018-01-09||拉卡拉支付股份有限公司||One kind of task scheduling system and processing method|
Family Cites Families (1)
|Publication number||Priority date||Publication date||Assignee||Title|
|US6573910B1 (en) *||1999-11-23||2003-06-03||Xerox Corporation||Interactive distributed communication method and system for bidding on, scheduling, routing and executing a document processing job|
Non-Patent Citations (1)
|See references of WO2006103460A1 *|
Cited By (1)
|Publication number||Priority date||Publication date||Assignee||Title|
|CN103679392B (en) *||2013-12-26||2018-01-09||拉卡拉支付股份有限公司||One kind of task scheduling system and processing method|
Also Published As
|Publication number||Publication date||Type|
|US5818469A (en)||Graphics interface processing methodology in symmetric multiprocessing or distributed network environments|
|US20020101431A1 (en)||Method and system for animating graphical user interface elements via a manufacturing/process control portal server|
|US20080104223A1 (en)||Plug-in accelerator|
|US20110313878A1 (en)||Made-to-order direct digital manufacturing enterprise|
|US20080174598A1 (en)||Design visualization system, apparatus, article and method|
|US20050243094A1 (en)||Systems and methods for providing an enhanced graphics pipeline|
|Regli||Internet-enabled computer aided design|
|US20060218478A1 (en)||Method and system for graphically navigating among stored objects|
|US7810025B2 (en)||File translation methods, systems, and apparatuses for extended commerce|
|US6931600B1 (en)||Integrating into an application objects that are provided over a network|
|US20100045662A1 (en)||Method and system for delivering and interactively displaying three-dimensional graphics|
|US20050010901A1 (en)||System and method for generating a graphical user interface (GUI) element|
|US6275866B1 (en)||Manipulation and coupling of object oriented components|
|US20020052807A1 (en)||Network architecture-based design-to-order system and method|
|US20080013860A1 (en)||Creation of three-dimensional user interface|
|US7671862B1 (en)||Systems and methods for providing an enhanced graphics pipeline|
|US20130144566A1 (en)||Real-time collaborative design platform|
|US20100042676A1 (en)||Device, system, and method of computer aided design (cad)|
|US20080104529A1 (en)||Draggable legends for sql driven graphs|
|US20110258573A1 (en)||Methods, Apparatus and Systems for Displaying and/or Facilitating Interaction with Secure Information via a Channel Grid Framework|
|US20080255945A1 (en)||Producing image data representing retail packages|
|US20130132466A1 (en)||3d modeling system distributed between a client device web browser and a server|
|US20090248831A1 (en)||Dynamic image composition|
|US20080301012A1 (en)||Methods and systems for distributing computer modeled product design and manufacture data to peripheral systems|
|17P||Request for examination filed||
Effective date: 20080207
|AK||Designated contracting states:||
Kind code of ref document: A1
Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR
|17Q||First examination report||
Effective date: 20080417
|DAX||Request for extension of the european patent (to any country) deleted|
|18D||Deemed to be withdrawn||
Effective date: 20081028