WO2012140360A1 - Procede et systeme de rendu d'une scene virtuelle en trois dimensions - Google Patents

Procede et systeme de rendu d'une scene virtuelle en trois dimensions Download PDF

Info

Publication number
WO2012140360A1
WO2012140360A1 PCT/FR2012/050783 FR2012050783W WO2012140360A1 WO 2012140360 A1 WO2012140360 A1 WO 2012140360A1 FR 2012050783 W FR2012050783 W FR 2012050783W WO 2012140360 A1 WO2012140360 A1 WO 2012140360A1
Authority
WO
WIPO (PCT)
Prior art keywords
rendering
data
metavoxels
metavoxel
level
Prior art date
Application number
PCT/FR2012/050783
Other languages
English (en)
Inventor
Abilio Machado
Marc Germain
Original Assignee
Real Fusio France
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Real Fusio France filed Critical Real Fusio France
Publication of WO2012140360A1 publication Critical patent/WO2012140360A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/10—Geometric effects
    • G06T15/40—Hidden part removal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
    • G06T17/005—Tree description, e.g. octree, quadtree
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2210/00—Indexing scheme for image generation or computer graphics
    • G06T2210/12—Bounding box
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2210/00—Indexing scheme for image generation or computer graphics
    • G06T2210/36—Level of detail

Definitions

  • the present invention relates to a rendering method using a partial load in RAM for models in three dimensions of very large size.
  • the requirements for massive digital data display are applications in which very large digital data are used, for example in the case of digital mock-ups used in CAD or architecture, in the case of geographic information systems representing land or cartography, in the case of application of the field of heritage conservation for models of monuments or works of art, in the field of medical imaging and in particular in the use of scanners.
  • the fidelity of the display should be preserved as much as possible, minimizing degradation if necessary while maintaining an acceptable refresh performance for a real-time application (rendering at a rate greater than 10 frames per second).
  • This type of method is satisfactory in that it actually makes it possible to make a very large 3D data set.
  • VRAM video memory
  • the present invention aims to solve all or part of the disadvantages mentioned above.
  • the present invention relates to a method for rendering a three-dimensional virtual scene comprising:
  • a first data preparation step comprising at least one step of grouping scene data into a data structure corresponding to a spatial division of the scene into a regular grid so as to form metavoxels, the digital data being stored in the data structure optimized under different levels of detail by metavoxel, the different levels corresponding to geometric simplifications, and
  • a second phase of real-time rendering using the geometric data structure for rendering at least one image comprising a step of determining the levels of detail to be used for each metavoxel taking into account a budget limit in memory of a computer on which is executed at least the rendering phase and performing a simulation of the occupation in memory of the metavoxels to be loaded according to their level of detail.
  • the system allows to take into account any type of data geometry (triangular mesh, parametric surface, voxels, brep %) as well as the insertion of metadata, that is data other than geometry, such as properties, material data, the producer and the generation date of an element of the geometry.
  • the arrangements according to the invention also make it possible to limit the losses during the conversion and during the display.
  • the arrangements according to the invention do not impose constraints on the size of the 3D data set, allow dynamic loading of this set of 3D data, and out-of-core operation. data being partially loaded in RAM.
  • the invention also relates to a system for implementing a method as described above, comprising: at least one computer enabling the execution of a preparation module implementing the steps of data preparation and a rendering module; and a database management system storing the metadata values.
  • the phase of the process corresponding to the preparation mechanism is an interruptible process, since the processing of each set of native data can be deferred in time, the concatenation step is responsible for grouping the sets.
  • the preparation mechanism is a batch process in the case where the native data includes a group of objects. Each group can be considered separately and the processing of each group is independent, these arrangements making it possible to prepare the data with a limited memory size and to set up a process using a partial load in RAM,
  • the mechanism of preparation is an automatic process, because the simplification algorithms are chosen so as to limit as much as possible the settings of the simplification parameters,
  • the mechanism of preparation is a treatment that can be performed multitasking. Indeed, following a first step of spatial division into metavoxels groups of objects, each metavoxel is processed independently, which reduces the preparation time of the database.
  • At least two simplified levels of detail are available for each metavoxel.
  • at least three levels of simplified details are available for each metavoxel.
  • the metavoxel isation comprises: a pre-calculation step of testing the intersection of the bounding boxes of the objects of the scene with the cells of the grids, and a step of testing the intersections between the triangles of the objects whose bounding box intersects with said cell.
  • the use of the position of the center of gravity allows unequivocal resolution of the membership between a cell and a triangle.
  • the scene data is stored as a first set comprising a unique identifier of a metavoxel and a list of sizes in the uncompressed state of each metavoxel according to the different levels of detail. ;
  • a second set comprising the geometrical data relating to each metavoxel, in particular sequentially, in different levels of detail.
  • the calculation of the levels of detail to be used for each metavoxel visible from a camera position for which the rendering is performed is carried out
  • the simulation of the memory budget is performed using the list of uncompressed sizes.
  • the lowest level of detail consisting in particular of impostors is always loaded into the memory of a computer on which is executed at least the rendering phase, and preferably in a video memory graphical acceleration means.
  • the data is stored compressed, decompressed on the fly.
  • the method comprises a first task of loading geometrical data of metavoxels from a mass memory, for example a hard disk and a random access memory of a computer on which at least the rendering phase, and a second task of loading metavoxel geometrical data between the random access memory of the computer on which at least the rendering phase is executed and a graphics acceleration means video memory, these two loading tasks being separated and interleaved, the first task being supported by a secondary thread on a microprocessor of the computer and the second task being taken over by a main thread, synchronization between the two tasks being performed using a loading tail and an unloading tail.
  • a computation of the priorities between the loadings / unloadings is carried out, this computation privileging all or part of the following transitions: the transitions saving a level of detail, the unloadings at the loadings, and the transitions towards a lower level of detail, and the absence of holes when displaying.
  • the rendering step comprises a calculation of all the potentially visible metavoxels from a camera position for which the rendering is carried out the determination of the occult metavoxels (hidden by other metavoxels) being performed using an intermediate rendering step based on the use of impostors taken into account in the visibility calculation for rendering an image subsequent to the rendering of the current image.
  • Figure 1 is an overall diagram of a hardware architecture for implementing the method according to the invention.
  • FIG. 2 is a flowchart of the data preparation part of a method according to the invention, limited to metadata and metavoxels.
  • Figures 3 to 5 illustrate the metavoxelization and voxeling steps of the process of Figure 2;
  • Figures 6, 7 and 8 illustrate steps of simplification of the geometry of the method of Figure 2;
  • Fig. 9 illustrates the storage organization of the data prepared following the steps illustrated in Fig. 2;
  • Figures 10 to 14 illustrate details of data storage for use in the second rendering mode without a graphics card.
  • Figure 15 illustrates the calculation of a voxel representation in plan form.
  • Figure 16 illustrates the calculation of a voxel representation as a primitive.
  • Figure 17 illustrates the organization of 3D elements as objects and groups.
  • FIG. 18 illustrates the steps of the method according to the invention relating to the mode of rendering with graphics card.
  • FIG. 19 illustrates the step of calculating the metavoxels visible from the camera mentioned in FIG. 18.
  • Fig. 20 illustrates the step of calculating the levels of detail mentioned in Fig. 18.
  • FIG. 21 illustrates the steps of the method according to the invention relating to the second rendering mode without a graphics card.
  • Fig. 22 illustrates the step of determining the rendering mode mentioned in Fig. 21.
  • Fig. 23 illustrates the rendering calculation step mentioned in Fig. 21.
  • Fig. 24 is a table illustrating a performance report of the method on a test platform for the second rendering mode with graphics card.
  • Metavoxel refers to a volume subdivision of the scene and the data structure corresponding to that subdivision.
  • a metavoxel can include including:
  • metavoxel is used to designate a first type of metavoxel consisting of a subdivision of the volume of the scene comprising a subset of 3D data, consisting in particular of triangles, and a second type of metavoxel, consisting of a subdivision of the volume of the scene, including either voxels or a new metavoxel subdivision.
  • voxel denotes a unit volume element of the scene that can be full or empty, which corresponds to the presence or absence of material.
  • a full voxel also corresponds to a representation of the native 3D data included in this volume element when rendered as a cube, a plane or a normal or a primitive, or a "level”. virtual "comprising a virtual subdivision into several cubes, as will be detailed below.
  • the "object group” or group is the name of a group of native geometric data groupings.
  • Native data usually includes a set of object groups.
  • this set comprises a plurality of groups, which can represent, for example, the exhaust, the engine, the bodywork, the passenger compartment, each including objects, such as a muffler, a catalytic filter, a steering wheel, a valve, a hose.
  • objects such as a muffler, a catalytic filter, a steering wheel, a valve, a hose.
  • Grouping of native group data is not required, however.
  • Metadata refers to non-geometric data such as properties, material data, creation history, producer and generation date of an element of geometry, but also membership information of an element of geometry to an object or group of objects.
  • a system according to the invention comprises a server 2 hosting a first data preparation module Prep, intended to transform the native data Nat into a data structure.
  • optimized OD compared to the native digital data, according to an automated processing using a partial load in RAM, and a second mod ule of rend u R1 or R2, respectively with and without graphics card.
  • These modules R1 and R2 render on the basis of the optimized data structure OD.
  • the purpose of the data preparation mechanism is to perform data preparation as quickly as possible, using batch multitasking, automatically, and reducing the number of processing parameters to obtain optimized data stored in the database. compact and organized way efficiently.
  • the data preparation provides two types of DB1 and DB2 data adapted to the two distinct rendering modes.
  • the rendering is performed on different types of heterogeneous hardware, either by realizing a R 1 using graphics acceleration (GPU) and the generic processor (s) (CPU) in the case where graphical acceleration means are present on the hardware 3, constituted for example by a personal computer intended for use with 3D log files, is rendered using only the generic processor (CPU) of a hardware 4 that does not include any means of graphic acceleration, type of hardware corresponding for example to a portable type computer for office operations or Internet consultation.
  • GPU graphics acceleration
  • s s
  • R1 or R2 rendering modules provide high-performance rendering with the highest possible level of detail. In all cases an on-screen display is made, this display can be degraded.
  • the rendering uses a partial load in RAM and takes into account a memory budget.
  • Means of protection and guarantee of the confidentiality of the data can also be implemented in an optional way.
  • the preparation modules Prep and render u R1 or R2 are shown in Figure 1 distributed on different hardware platforms. It is possible in this case to set up a mechanism for replication of DB1 or DB2 data to the hardware platforms 3 and 4 on which the rendering operations are executed.
  • Figure 2 shows both a processing of the metadata M D and geometric data D present in the native data Nat.
  • Prep rendering steps The purpose of Prep rendering steps is to achieve a compact and efficient organization for rendering out of the kernel.
  • an EP2 step of creating a metadata dictionary is performed so as to separate the metadata and to obtain key K / value V key pairs.
  • a differentiated storage is operated.
  • the keys K are injected into the geometry in a step EP4.
  • V values are stored out of the geometry especially in a database management system (DBMS).
  • DBMS database management system
  • the advantage of this approach is to allow interaction by metadata (grouping, highlighting / hiding objects, identifying objects).
  • the keys K are nested in the geometry D in the form of non-geometric data attributes.
  • these keys can be entered in the triangle data as vertex attributes, or in the voxel data as a bit field in the voxel load.
  • the keys are generated automatically.
  • an EP3 step it is possible to replicate the metadata database on a client station 3, 4, in order to facilitate the deployment of the metadata on the client station.
  • DBMS database management system
  • a light mono-user DBMS for example on a client station 3, 4 or executes a rendering module R1 or R2.
  • the replication step is a data extraction necessary from the first DBMS to generate a smaller database in the second DBMS.
  • the geometric data D are numerical representations constituted by meshes, implicit surfaces, or other representations, for example of the brep type.
  • the conversion step consists in transforming, using connectors or adapters, the various representations of the Nat native data into a common representation expected by the subsequent steps of the method, ensuring maximum fidelity of the data.
  • a metavoxelization step EP6 is performed.
  • Metavoxelization consists of associating the elements of numerical data D, constituted in particular by triangles, with the cubes of a regular grid dividing the space in which is plunged the 3D scene whose rendering must be carried out.
  • Metavoxelization involves a preliminary step in calculating the bounding boxes (BEs) of the objects in the scene. These boxes are aligned on the axes of an Axis Aligned Bounding Box (AABB) ( Figure 3). These bounding boxes are calculated in the local coordinate system of the object, and the position of the object in the scene's global coordinate system is imported from the metadata.
  • BEs bounding boxes
  • AABB Axis Aligned Bounding Box
  • This preliminary step is preferably performed when importing metadata. Subsequently, the bounding boxes are expressed in the common or global coordinate system.
  • Metavoxelization then includes:
  • the na ⁇ ve test causes a computational cost proportional to n * p * k where n represents the number of cells of the grid, p the number of objects of the scene and k the average number of triangles per object, whereas the The above-described method causes a computational cost proportional to n * p + m * k where m represents the number of cells potentially containing elements of the geometry, this number being in general well below to n.
  • a Lcell list associates each geometry element with a set of grid cells containing geometry. This list is formed by inserting for each object of the scene, the cells of the grid having an intersection with its bounding box. Once the Lcell list has been constructed, a run of this list allows to build, a list Lgeom which for each cell, associates the objects presenting an intersection said cell is constituted.
  • FIG. 3 represents four cells CG0, CG1,
  • Lcell [O1] ⁇ CG0, CG2 ⁇
  • Lcell [O2] ⁇ CG0, CG1 ⁇
  • the Lgeom lists are then constructed by crossing the values of the Lcell lists.
  • the intersections of the triangles of the objects with the cells of the grid are realized.
  • the list of intersected objects Lgeom is considered, and for each object of this list, an intersection test is performed for each triangle T of the object to determine whether the center of gravity of this triangle is included in the CG cell.
  • FIG. 4 represents two CGO and CG1 cells, and an object on these two cells comprising two triangles T1 and T2.
  • Metavoxels that is to say subsets of 3D data belonging to a cell of the grid, constituted in particular by triangles, are thus constituted.
  • Each metavoxel comprises a set of triangles, the intersected triangles of the objects are stored contiguously while keeping a metadata M corresponding to an identifier of the object to differentiate them.
  • a first object O1 comprising two triangles
  • the first triangle being formed comprising three vertices corresponding to the positions P0, P1, P2
  • the second triangle being formed by the vertices corresponding to the positions P1, P2 and P3
  • a second object O2 comprising a triangle formed by the vertices at the positions P4, P5, P6,
  • the list of the vertices LS and the list of the indices L1 can be stored from the following way:
  • LS ⁇ (PO; M (O1)) (P1; M (O1)) (P2; M (O1)) (P3; M (O1)) (P4; M (O2))
  • the keys K of the metadata make it possible to retrieve the values in the dictionary of metadata and to differentiate the elements of the same metavoxel belonging to objects. different.
  • a vertex can indeed contain data of:
  • an EP7 simplification step is performed.
  • the goal is to generate for the geometrical data contained in each metavoxel several levels. (LOD) so that native geometry data can be displayed with limited random access memory (RAM).
  • LOD geometrical data contained in each metavoxel several levels.
  • n0 a level n0 corresponding to the native data, simply using the result of the metavoxelization step and the contiguous storage of these data;
  • the objective is to simplify the outer envelope of the objects.
  • Two stages are implemented, as illustrated in FIG. 7: the mesh is plunged into a grid G, to reduce the computation time, then, for each cube of the grid and each vertex s, in this cube, the distance between two somets is compared to a determined limit d. If the distance is less than d, the vertices are merged. In the figure the sets of vertices ⁇ s1; s2 ⁇ and ⁇ s3; s4 ⁇ are merged.
  • the limit d can be set automatically for example as a fraction of the radius of the enclosing sphere of the mesh.
  • a rendering is made for a limited number of points of view, for example 6 (front, back, top, bottom, left, right), then the The rendering result is captured in a texture, then the impostor I is generated as nv quadrilaterals on which the nv textures are plastered.
  • a concatenation and compression step EP8 is performed.
  • the goal of this step is to group the data into one or more meta-files, to facilitate data deployment, and in particular to speed up copying during installation, and to speed up rendering by optimizing transfers between the disk (HDD) and the live memory (RAM) by use of the cache (H DD) and a transfer mechanism between the disk (H DD) and the random access memory (RAM) of the disk operating system.
  • the storage is in the form of two sets, as illustrated in FIG. 9: a first set comprising indexes, and a second set comprising the data.
  • Each mvID index is a unique identifier that corresponds to a metavoxel and provides access to it.
  • the uncompressed size T of the metavoxel is also stored, for the different levels of detail, so as to be able to predict the memory budget when rendering, which will be detailed later.
  • Data is stored in a second set sequentially, separated into Bk blocks the size of a cluster of multiples of 512
  • the data is stored compressed and is decompressed on the fly.
  • the data contains Metavoxels stored in levels of detail nO, n1, n2, n3, n4.
  • an EP9 voxelization step is performed.
  • a metavoxel subdivision of higher level of detail is performed.
  • Each top-level retail metavoxel can in turn be divided into a higher-level metavoxel set of detail.
  • a recursive regular grid is used which has several levels of regular grid definitions.
  • a metavoxel of a given level of the grid corresponds to a subdivision of a lower level metavoxel of detail.
  • intermediate divisions or an intermediate level i.O can be defined.
  • Figure 12 illustrates the structure of a unique metavoxelID metavoxel identifier, in the case where four grid levels are used.
  • the four levels correspond to:
  • This identifier includes:
  • depth information on the depth of the metavoxel considered in the depth levels of the regular grid position information in the different grid levels and in particular:
  • the identifier ID Scene of the metavoxel of the base level corresponding to the position along three axes XYZ relative to the global reference of the scene, this position being indicated by positioning indices in the grid (position identical to the corresponding metavoxel of the step EP6);
  • Pos 0, Pos 1, Pos. 2 can be decomposed into two indices LvlOiD and LvM iD corresponding to the intermediate levels of the grid at each level.
  • the Meta Voxel identifier ID is a unique identifier, used for all the metavoxels of the different depth levels of the regular grid.
  • a voxel corresponds to the presence or absence of material: at rendering, this volume can be the subject of several representations.
  • the full voxels can be represented by cubes.
  • the volume of the voxel is represented by a subdivision into cubes corresponding to a subdivision of the voxel volume at 2 on each axis. These cubes can be full or empty. For example, 8 cubes are defined. These cubes share the same definition of the normal which corresponds to the normal of the father voxel.
  • a corresponding normal it is possible for example to calculate a normal corresponding to the average of the normals of the triangles contained in the volume intended to be represented by the voxel.
  • the first step consists of calculating a normal representing the voxel the best, for example as an average normal on the triangles of the geometry, then project all the vertices A of the geometry into a point B on the line defined by the normal and the center of the voxel.
  • (A) - A first type of primitives from 6 normals corresponding to planes intersecting the diagonal cube, thus defining 12 prismatic half-cubes as primitives on both sides of each plane,
  • (C) - A third type of primitives from 8 subdivisions of the cube as cubes having a dimension edge divided by 2, which corresponds to the definition of 8 primitives.
  • a test is performed to identify whether all the triangles are contained in a single cube having an edge corresponding to half of the voxel according to the third type of primitive.
  • Voxalization is performed independently by the different threads or processes for each metavoxel in the multilevel grid, starting from the root and traversing the voxel tree.
  • a second reorganization step makes it possible to gather contiguously the data relating to all the voxels son of the same parent voxel, which corresponds to a reorganization of the voxels.
  • Voxelization is performed on this group of metavoxels, independently using a multiprocess and multithreaded approach for voxelization.
  • the storage is in the form of two sets, as illustrated in FIG. 10: a first set comprising indexes, and a second set comprising the data.
  • the goal is to optimize transfers to disk (HDD) by sequential storage but allowing direct access.
  • the data is stored as blocks.
  • the blocks include a header and payloads of the voxels.
  • the use of a header allows a saving of storage space and direct access to data.
  • the header has an IndexTbl index table of RAM
  • This index table provides access to the entire payload in the cache (RAM) while it is stored non-contiguously in this cache.
  • the RAM cache is allocated by the method to perform the loading of the voxel payloads.
  • the index table includes:
  • a usage counter corresponding to the number of threads having access to the data at a given moment, in order to identify whether it can be deleted from the cache or not;
  • the header also includes a presence mask that allows to indicate for each voxel if it is empty or full, and this for each level of depth of the grid.
  • the mask may include a 0 to indicate an empty voxel and a 1 for a full voxel (i.e., containing geometry). This presence mask simplifies the calculations intersection. There is no need to access the data for each voxel.
  • a first Msk Voxel presence mask iO is stored for voxels representing a subdivision at the intermediate level of each metavoxel as detailed with reference to FIG. 11, and a set of presence mask Msk i. 1 is stored for each of these intermediate level voxels. Offset information is also stored which makes it easy to find the voxel payload.
  • FIG. 13b makes it possible to describe the structure of masks and offsets in a simplified example by considering 4-bit masks for the i.O and i.1 masks.
  • a table is constituted which stores for each entry of the mask i.O a mask i.1 and an offset corresponding to the number of full voxels listed before the current intermediate voxel.
  • a mask i.1 is stored with, for example, the content [0,1, 0, 1] which thus comprises two full voxels.
  • An offset or null offset is stored because it is the first intermediate voxel i.O processed.
  • the second line corresponds to an entry at 0 in the i.O mask.
  • the third line corresponds to an entry at 1 in the mask i.O.
  • a mask i.1 is stored with for example the following content [1, 0, 1, 1] which thus comprises three full voxels.
  • the fourth line corresponds to an entry at 1 in the mask iO a mask i.1 is stored with for example the following content [0,0, 1, 1] which therefore comprises two full voxels.
  • An offset or offset of (2 + 3) times the payload size of a PISize voxel is stored corresponding to both voxels full of the first line and the three full voxels of the third line.
  • the offset corresponds to the size of the PL payload of a voxel multiplied by the cumulative number of full voxels in the previous rows.
  • bit 3 of the mask i.O is at 1 (if not the voxel that one considers is empty);
  • nbVoxPlein the number of full voxels (nbVoxPlein) is counted before the voxel considered.
  • nbVoxPlein is 1 because only bit 2 is 1 before bit 3.
  • the metavoxel data storage structure further includes a data field that includes the payloads of the full voxels.
  • the payloads of the voxels are stored sequentially.
  • the payload includes the description of the voxels.
  • Node intermediate voxel that points to voxels of a higher level in the tree
  • the elements can be: either a representation by plane / normal, or a primitive, of cubic or other type.
  • Storage of a payload includes:
  • the useful area includes a pointer in the cache to a higher-level, higher-level metavoxel, and filler.
  • the useful area comprises:
  • an identifier of a normal obtained from the native geometry represented by the primitive Pre-defined discretized possible normal values are stored in a table.
  • the normal identifier corresponds to an entry in this table.
  • the useful zone includes:
  • the normals can be discretized on 14 bits, the possible primitives are 2 ⁇ 5 and the possible normals discretized for this primitive with the number of 2.
  • the tires are used and stored on the fly during loading.
  • the identifiers or KG KO keys are split and stored distributed over the different grid levels, in order to take into account the limited payload size per voxel.
  • This metadata is stored in tables as follows:
  • an IDGrTbl table of group identifiers KG and / or group combination is stored for all metavoxels.
  • an IDObjTbl table of identifiers or KO keys of objects or combination of objects is stored at the level of metavoxels of lower level of detail.
  • metavoxel of higher level of detail When selecting an element of the scene, it is possible from the metavoxel of higher level of detail to obtain information on the groups of objects present in said metavoxel, and then to cross this information with the identifiers of the elements. objects stored at the lowest level of detail metavoxel to limit the selection of possible objects.
  • Figure 17 illustrates an example of groups and objects contained in these groups.
  • two groups Gn and Gr 2 are respectively defined object comprising objects On, ⁇ 12, ⁇ 13, ⁇ 4 ⁇ 15, ⁇ 16 and ⁇ 21, 022-
  • a MV intakevoxel 0 level 0 includes objects On, and ⁇ 12 ⁇ 21.
  • the IDGrTbl and IDOTbl tables for this metavoxel MV 0 are then reproduced below:
  • Level 1 metavoxel MV1 For Level 1 metavoxel MV1, only object group identifiers or object group combinations are stored. Thus, for the metavoxel MV1, only the key KG1 will be stored because the metavoxel MV1 contains only objects of the group Gn.
  • the first rendering mode R1 uses the graphics acceleration means (GPU) and the generic processor (CPU)
  • the goal is to achieve a rendering as fast as possible in terms of loading time and display frequency, while respecting the RAM and video (VRAM) budget and maximizing the rendering quality corresponding to the levels. Retail.
  • the key K is retrieved from the 3D display.
  • the GPU renders in a display mode that allows to associate a key with a color code.
  • the corresponding rendering buffer is then retrieved from the CPU which identifies the keys K in this buffer.
  • the dictionary is then interrogated using the key K in a step ER1_9.
  • a visual return on the 3D display can be performed in a step ER1_8, for example in the form of highlighting or obscuring an object, or else displaying properties, filtering Datas.
  • HDD disk
  • RAM random access memory
  • VRAM video memory
  • HDD-> RAM loading is done on a secondary thread and RAM-> VRAM loading is done on a main thread.
  • Synchronization between the two loading threads is done using a loading and unloading queue. These tails can fragment loading tasks to avoid latency too long.
  • the treatment of unloading tails is also divided into two parts with:
  • the requests for loading or updating are determined by realizing in a step ER1_2 a calculation of all the metavoxels visible from the camera and then calculating the levels of detail for each of these metavoxels in a step ER1_3.
  • step ER1 _2 for calculating visible metavoxels 11 aims to eliminate as much as possible of non-visible metavoxels, that is to say, as illustrated in FIG. 19: metavoxels 10 not contained in the frustum of the camera, represented hatched and metavoxels 12 hidden by other metavoxels, represented filled with dots.
  • an occlusion request is made on the basis of the first image in order to determine if an occluder element is visible relative to the other occluders elements from the point of view of the camera;
  • Differentiating the occluder element rendering steps from the occlusion queries smooths the latency introduced by these occlusion queries.
  • the step ER1_3 for calculating the levels of detail is intended to determine the level of detail of each metavoxel to obtain the best display and respect the memory constraints.
  • This calculation is done by simulating a loading of the metavoxels on a set of sectors corresponding to zones at a given distance from the camera, then, for each sector, to determine its level of detail, then to cumulate the corresponding memory budget by using the list of uncompressed T sizes.
  • FIG. 20 This operation is illustrated in FIG. 20 in which five sectors S0 to S4 are illustrated.
  • the metavoxels M hatched arranged in the S3 and S4 sectors will have to be loaded with a low level of detail because the budget limit is exceeded.
  • the HDD-> RAM thread performs an update request. Every t seconds, the secondary thread RAM-> VRAM checks requests for update queries for loading and unloading queues. If a query is encountered, the metavoxels are actually loaded from HDD to RAM.
  • the lowest level of detail, including the impostors I is always loaded in VRAM video memory.
  • Updating the unload queue consists of unloading metavoxels from the VRAM video memory.
  • the loading queue allows:
  • RAMA / RAM storage duplicates are avoided thanks to the chosen data structures and in particular to the storage of metadata in the geometrical data, it is not necessary to keep the geometry in RAM.
  • Calculation of priorities between loadings / unloads aims to limit loading latency, maximize memory gains and avoid holes when displaying.
  • the order of priority may be the following:
  • b- transitions from an imposter level (n4) to a level including geometry with a high level of detail (nO to n2)
  • e - transitions from an imposter level (n4) to a level with geometry of low level of detail (n3).
  • this second rendering mode only uses the generic processor (CPU), without using graphic acceleration means.
  • This second mode is to render as quickly as possible in terms of loading time and display frequency respecting the available RAM RAM budget, maximizing the quality of rendering, without a video card providing a 3D acceleration, that is to say without dedicated means of triangles rendering and without available video memory (VRAM).
  • the processing of a request for metadata is performed in the following manner, similar to that of the first rendering mode.
  • the key K is retrieved from the 3D display.
  • the CPU can obtain, during rendering, the value of the key stored in the geometric data for the considered point.
  • the dictionary is then interrogated using the key K in a step ER2_9.
  • a visual feedback on the 3D display can be performed in a step ER2_5, for example in the form of highlighting or obscuring an object, or else displaying the properties, filtering Datas.
  • 3 levels of caches can be used to limit memory consumption and maximize rendering quality.
  • a first cache level corresponds to the metavoxels and contains the voxels of the level 0 grid. All level 0 voxels are stored in this cache from the start of rendering.
  • a second level of cache corresponds to the metavoxels that contain the voxels of the top level grid at level 0.
  • the loading mode consists in loading the voxels son of the voxels G0 until saturation of the memory.
  • the loading mode in this first cache is as follows: following a calculation of the visible metavoxels2D, the voxels G0 are loaded until saturation of the memory, by loading the maximum possible according to the point of view and displacement.
  • a third cache level is a circular buffer for loading the voxels corresponding to the depth level of the highest recursive grid.
  • the voxels to be loaded are determined using a radius throw, when crossing the regular recursive grid.
  • This third cache is a buffer in the form of a circular buffer. When a cache element is used, its reuse index is increased. The choice of items to replace in the cache is the least used item in the cache.
  • This third cache is used for a specific HD + rendering mode that will be detailed later.
  • a step ER_2_6 of determining the rendering mode is carried out, to determine a rendering mode to display the fastest with the best quality possible.
  • voxels of the level 0 and possibly higher level grid are displayed. Requests for loading metavoxels from the top level grid are started and the corresponding metavoxels are loaded as the camera moves. To avoid the latency of loading metavoxels above level 0, rendering is performed with metavoxels greater than 0 that are available after they are loaded, and the rest of the visible metavoxels keep level 0.
  • the definition of the rendering window is decreased, for example by being d ivised by two. This mode is activated when moving the camera;
  • a fourth type of HD + rendering can be made, at the definition of the rendering window.
  • all metavoxels with the highest level of detail visible from the camera are loaded. In order to be able to consider them all, they are circularly loaded into the third cache.
  • Figure 22 illustrates the relationships and activations of the different rendering modes. From an "inactive” state, if an "in mvt" event corresponding to a camera movement is detected, a transition to a state of calculation of an SD image "SD image calculation” is triggered. From this state, a transition to an "inactive in motion” state is triggered when the SD image is ready. A transition back to the "SD image calculation” state is triggered if the camera settings are changed to "Camera Update”. From the "SD image calculation” or “Inactive in mvt” states, a transition is triggered to a calculation state of an MD image upon detection of a "late mvt" camera movement end. from this state a transition to an intermediate state when the calculation of the image MD is completed.
  • a calculation of an image in HD + mode can be triggered in a "HD + image calculation" state, provided that an HD image has already been calculated.
  • a calculation state without displaying an SD image can be provided, in order to optimize the calculation of visible objects by an occlusion test (voxels hidden by other voxels).
  • An SD rendering makes it possible to build all the metavoxels V1 visible from the camera, only these voxels are then loaded when computing an MD or HD image.
  • this rendering can in particular be carried out by the so-called 3D-DDA method, illustrated in FIG. 23.
  • Each element of the grid is examined along the radius.
  • the crossing of the grid is recursive. Below is an example with reference to Figure 21 and limited to two grid level. Of course, additional grid levels can be used.
  • the cursor advances along the radius.
  • a solid element at level 0 is encountered by the ray, such as voxel V0 in FIG. 21, the ray travels the level 1 elements contained in the metavoxel v0.
  • the cursor advances along the radius.
  • a solid element is encountered, such as voxel v3 of Figure 21: the crossing stops, the lighting is calculated, the voxel cache is updated.
  • Figure 24 shows performance data on a test platform consisting of a consumer computer, whose CPU includes a 4-core processor (Intel Core2Quad Q6600, 2.40 Ghz), a RAM of 2 GB , a graphics card: NVidia GeForce 8800 GTX with a 768 MB video memory (VRAM) whose maximum effective capacity is 30 million triangles @ 10fps.
  • a 4-core processor Intel Core2Quad Q6600, 2.40 Ghz
  • RAM of 2 GB
  • graphics card NVidia GeForce 8800 GTX with a 768 MB video memory (VRAM) whose maximum effective capacity is 30 million triangles @ 10fps.
  • a first model Md1 comprising 35 GB of data, 30 billion triangles, 600,000 objects and 30 groups;
  • a second model Md2 comprising 10 GB of data, 40 million triangles, 20000 objects and 7 groups.
  • GPUs GPUs
  • CPUs Other rendering engines

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Graphics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Geometry (AREA)
  • Software Systems (AREA)
  • Image Generation (AREA)

Abstract

La présente invention concerne un procédé de rendu d'une scène virtuelle en trois dimensions comprenant: une première phase de préparation de données comprenant au moins une étape de regroupement de données de la scène dans une structure de données (OD) correspondant à une division spatiale de la scène en une grille régulière de façon à former des métavoxels, les données numériques étant stockées dans la structure de donnée optimisée (OD) sous différents niveaux de détail par métavoxel, les différents niveaux correspondant à des simplifications géométriques, et une seconde phase de rendu temps réel utilisant la structure de données géométriques (OD) pour le rendu d'au moins une image comprenant une étape de détermination des niveaux de détails à utiliser pour chaque métavoxel prenant en compte une limite de budget en mémoire d'un ordinateur sur lequel est exécuté au moins la phase de rendu et effectuant une simulation de l'occupation en mémoire des métavoxels à charger suivant leur niveau de détail.

Description

Procédé et système de rendu d'une scène virtuelle en trois dimensions
Domaine technique et état de la technique
La présente invention a pour objet un procédé de rendu utilisant un chargement partiel en mémoire vive pour des modèles en trois dimensions de très grande taille.
Les besoins d'affichage de données numériques massives concernent des applications dans lesquelles des données numériques de très grande taille sont utilisées, par exemple dans le cas de maquette numérique utilisées dans la CAO ou l'architecture, dans le cas de systèmes d'information géographiques représentant des terrains ou une cartographie, dans le cas d'application du domaine de la conservation du patrimoine pour des modèles de monuments ou d'œuvres d'art, dans le domaine de l'imagerie médicale et notamment dans l'utilisation de scanners.
Il convient de préserver autant que possible la fidélité de l'affichage, en opérant le cas échéant une dégradation minimisée tout en maintenant une performance de rafraîchissement acceptable pour une application temps réel (rendu à une fréquence supérieure à 10 images par secondes).
A titre d'exemple, il est connu du document US6933946 de procéder à un rendu de type utilisant un chargement partiel en mémoire vive avec une phase de préparation des données.
Ce type de procédé donne satisfaction en ce qu'il permet effectivement de réaliser un rendu d'ensemble de données 3D de très grande taille.
Il apparaît toutefois que ce type de procédé n'est pas adapté à un parc de machines hétéroclites aux capacités limitées, et comprenant notamment une taille de la mémoire vive (RAM) inférieure à 3GB sur des systèmes 32bits, présentant ou non un matériel d'accélération de l'affichage 3D de type carte graphique (GPU).
Dans le cas ou un tel matériel est présent, sa capacité maximale effective d'affichage est limitée, de l'ordre de 30 millions de triangles par seconde à l'heure actuelle, et la mémoire vidéo (VRAM) est également limitée, par exemple à une valeur de l'ordre de 2 Go.
Bien entendu, les progrès matériels permettent d'envisager des augmentations de ces capacités, toutefois ces progrès ne concernent pas le parc installé et ne permettent pas d'envisager à moyen terme une prise en charge de l'affichage d'ensemble massif de données 3D sur un matériel informatique moyen et d'entrée de gamme.
Exposé de l'invention
La présente invention a pour but de résoudre tout ou partie des inconvénients mentionnés ci-dessus.
A cet effet, la présente invention concerne un procédé de rendu d'une scène virtuelle en trois dimensions comprenant:
une première phase de préparation de données comprenant au moins une étape de regroupement de données de la scène dans une structure de données correspondant à une division spatiale de la scène en une grille régulière de façon à former des métavoxels, les données numériques étant stockées dans la structure de donnée optimisée sous différents niveaux de détail par métavoxel, les différents niveaux correspondant à des simplifications géométriques, et
une seconde phase de rendu temps réel utilisant la structure de données géométriques pour le rendu d'au moins une image comprenant une étape de détermination des niveaux de détails à utiliser pour chaque métavoxel prenant en compte une limite de budget en mémoire d'un ordinateur sur lequel est exécuté au moins la phase de rendu et effectuant une simulation de l'occupation en mémoire des métavoxels à charger suivant leur niveau de détail.
Grâce aux dispositions selon l'invention, plusieurs représentations alternatives de complexités décroissantes correspondant aux différents niveaux de détails sont d ispon ibles pour chaque métavoxel. Cette variété des représentations permet de sélectionner lors du rendu celle qui offrira le meilleur compromis entre qualité visuelle et vitesse de traitement. Les différents niveaux de détails correspondent par exemple à une géométrie évidée, une géométrie simplifiée, à des imposteurs, etc,.
Ainsi, un rendu fidèle de données 3D numérique massive est obtenue. Le système permet de prendre en compte tout type de donnée numérique et de géométrie (maillage triangulaire, surface paramétrique, voxels, brep... ) ainsi que l'insertion de métadonnées, c'est-à-dire de données autres que la géométrie, comme des propriétés, des données sur les matériaux, le producteur et la date de génération d'un élément de la géométrie.
Les dispositions selon l'invention permettent également de limiter les pertes lors de la conversion et lors de l'affichage. Les dispositions selon l'invention n'imposent pas de contrainte sur la taille de l'ensemble de données 3D, permettent un chargement dynamique de cet ensemble de données 3D, et un fonctionnement hors cœur (« out-of-core »), les données étant partiellement chargées en mémoire vive (RAM).
L'invention concerne également un système destiné à la mise en œuvre d'un procédé tel que décrit précédemment, comprenant : au moins un ordinateur permettant l'exécution d'un module de préparation mettant en œuvre les étapes de préparation des données et d'un module de rendu; et un système de gestion de base de données stockant les valeurs de métadonnées.
La phase du procédé correspondant au mécanisme de préparation est un processus interruptible, car le traitement de chaque ensemble de la donnée native peut être différé dans le temps, l'étape de concaténation se charge de regrouper les ensembles.
Le mécanisme de préparation constitue un traitement pouvant être réalisé par lots dans le cas où les données natives comportent un ensemble de groupe d'objets. Chaque groupe peut être considéré séparément et le traitement de chaque groupe est indépendant, ces dispositions permettant de préparer la donnée avec une taille mémoire limitée et de mettre en place un processus utilisant un chargement partiel en mémoire vive,
Le mécanisme de préparation est un processus automatique, car les algorithmes de simplification sont choisis de manière à limiter au maximum les réglages des paramètres de simplification,
Enfin, le mécanisme de préparation est un traitement pouvant être réalisé de façon multitâche. En effet, suite à une première étape de division spatiale en métavoxels des groupes d'objets, chaque métavoxel est traité de manière indépendante, ce qui permet de réduire le temps de préparation de la base de données.
Selon un aspect de l'invention, au moins deux niveaux de détail simplifiés sont disponibles pour chaque métavoxel . Selon un autre aspect de l'invention, au moins trois niveaux de détails simplifiés sont disponibles pour chaque métavoxel.
Selon un aspect de l'invention, la métavoxel isation comprend : une étape de pré calcul consistant à tester l'intersection des boîtes englobantes des objets de la scène avec les cellules de la grilles, et une étape de test des intersections entre les triangles des objets dont la boîte englobante forme une intersection avec ladite cellule.
Selon un autre aspect de l'invention, l'utilisation de la position du centre de gravité permet une résolution univoque de l'appartenance entre une cellule et un triangle.
Selon un autre aspect de l'invention, les données de la scène sont stockées sous forme d'un premier ensemble comprenant un identifiant unique d'un métavoxel et une liste des tailles à l'état décompressé de chaque métavoxel selon les différents niveaux de détails; et
d'un second ensemble comprenant les données géométriques relatives à chaque métavoxel, notamment de manière séquentielle, dans différents niveaux de détails.
Selon un autre aspect de l'invention, le calcul des niveaux de détail à utiliser pour chaque métavoxel visible depuis une position de caméra pour laquelle le rendu est effectué est réalisé,
en prenant en compte un ensemble de secteurs correspondant à des zones à une distance donnée de la position de caméra,
en attribuant un niveau de détail à l'ensemble des métavoxels présents dans un même secteur, les niveaux de détails étant décroissants avec l'éloignement de la position de la caméra de façon à adapter un espace mémoire simulé nécessaire au chargement des métavoxels sur l'ensemble des secteurs à une limite de budget mémoire disponible.
Selon un autre aspect de l'invention, la simulation du budget mémoire est réalisée en utilisant la liste des tailles décompressées.
Selon un autre aspect de l'invention, le niveau de détail le plus bas, constitué notamment par des imposteurs est toujours chargé dans la mémoire d'un ordinateur sur lequel est exécuté au moins la phase de rendu, et de préférence dans une mémoire vidéo de moyens d'accélération graphique.
Selon un autre aspect de l'invention, les données sont stockées compressées, décompressées à la volée. Selon un autre aspect de l'invention, le procédé comprend une première tâche de chargement des données géométriques de métavoxels à partir d'une mémoire de masse, par exemple un disque dur et une mémoire vive d'un ordinateur sur lequel est exécuté au moins la phase de rendu, et une seconde tâche de chargement des données géométriques de métavoxels entre la mémoire vive de l'ordinateur sur lequel est exécuté au moins la phase de rendu et une mémoire vidéo de moyens d'accélération graphique, ces deux tâches de chargement étant séparées et entrelacées, la première tâche étant prise en charge par un thread secondaire s'effectuant sur un microprocesseur de l'ordinateur et la seconde tâche étant prise charge par un thread principal, la synchronisation entre les deux tâches étant effectuée à l'aide d'une queue de chargement et d'une queue de déchargement.
Selon un autre aspect de l'invention, un calcul des priorités entre les chargements/déchargements est réalisé, ce calcul privilégiant tout ou partie des transitions suivantes: les transitions faisant gagner un niveau de détail, les déchargements aux chargements, et les transitions vers un niveau de détail plus bas, et l'absence de trous lors de l'affichage.
Selon un autre aspect de l'invention, l'étape de rendu comprend un calcul de l'ensemble des métavoxels potentiellement visibles depuis une position de caméra pour laquelle le rendu est effectué la détermination des métavoxels occultés (cachés par d'autres métavoxels) étant effectué à l'aide d'une étape de rendu intermédiaire basée sur l'utilisation d'imposteurs pris en compte dans le calcul de visibilité pour le rendu d'une image ultérieure au rendu de l'image courante. Brève description des dessins
L'invention sera mieux comprise à l'aide de la description détaillée qui est exposée ci-dessous en regard du dessin annexé dans lequel :
La figure 1 est un schéma d'ensemble d'une architecture matérielle permettant de mettre en œuvre le procédé selon l'invention.
La figure 2 est un organigramme de la partie de préparation des données d'un procédé selon l'invention, limitée aux métadonnées et aux métavoxels.
Les figures 3 à 5 illustrent les étapes de métavoxelisation et de voxélisation du procédé de figure 2 ; Les figures 6, 7 et 8 illustrent des étapes de simplification de la géométrie du procédé de figure 2 ;
La fig ure 9 illustre l'organisation du stockage des données préparées suite aux étapes illustrées sur la figure 2 ;
Les figures 10 à 14 illustrent des détails du stockage des données destiné à une utilisation dans le second mode de rendu sans carte graphique.
La figure 15 illustre le calcul d'une représentation de voxel sous forme de plan.
La figure 16 illustre le calcul d'une représentation de voxel sous forme de primitive.
La figure 17 illustre l'organisation des éléments 3D sous forme d'objet et groupes.
La figure 18 illustre les étapes du procédé selon l'invention relative à au mode de rendu avec carte graphique.
La figure 19 illustre l'étape de calcul des métavoxels visibles depuis la caméra mentionnée sur la figure 18.
La figure 20 illustre l'étape de calcul des niveaux de détails mentionnée sur la figure 18.
La figure 21 illustre les étapes du procédé selon l'invention relatifs au second mode de rendu sans carte graphique.
La figure 22 illustre l'étape de détermination du mode de rendu mentionnée sur la figure 21 .
La figure 23 illustre l'étape de calcul du rendu mentionnée sur la figure 21 .
La figure 24 est un tableau illustrant un relevé de performance du procédé sur une plateforme de test pour le second mode de rendu avec carte graphique.
Description détaillée de modes de réalisation particuliers I. Définitions
Le terme « métavoxel » désigne une subdivision en volume de la scène et la structure de donnée correspondant à cette subdivision.
Un métavoxel peut comprendre notamment comprendre :
- un sous-ensemble de données 3D, ou
- une représentation de ces données sous forme d'un ensemble de voxel, ou encore - une nouvelle subdivision en métavoxels.
Dans la description ultérieure, le terme métavoxel est employé pour désigner un premier type de métavoxel consistant une subdivision du volume de la scène com prenant un sous-ensemble de données 3D, constitués notamment par des triangles, et un second type de métavoxel, consistant en une subdivision du volume de la scène, et comprenant soit des voxels, soit une nouvelle subdivision en métavoxel.
Le terme « voxel » désigne un élément de volume unitaire de la scène pouvant être plein ou vide, ce qui correspond à la présence ou non de matière.
Un voxel plein correspond également à une représentation des données 3D natives comprises dans cet élément de volume lors du rendu sous forme d'un cube, d'un plan ou d'une normale ou d'une primitive, ou encore d'un « niveau virtuel » comprenant une subdivision virtuelle en plusieurs cubes, comme cela sera détaillé ci-dessous.
L e t e rm e « groupe d'objet » ou groupe est relatif à des regroupements de données géométriques natives. Les données natives comportent usuellement un ensemble de groupe d'objets. Par exemple, dans le cas d'un ensemble de données natives représentant une voiture, cet ensemble comprend une pluralité de groupes, qui peuvent représenter par exemple l 'échappement, le moteur, la carrosserie, l 'habitacle, chaq ue g rou pe comprenant des objets, comme par exemple un pot d'échappement, un filtre catalytique, un volant, une soupape, une durite. Le regroupement des données natives en groupe n'est toutefois pas obligatoire.
L e t e r m e « métadonnées » concerne des données non géométriques comme des propriétés, des données sur les matériaux, l'historique de création, le producteur et la date de génération d'un élément de la géométrie, mais aussi des informations d'appartenance d'un élément de la géométrie à un objet ou à un groupe d'objet. II. Architecture du système
Nous allons à présent décrire un procédé et un système selon l'invention en référence aux figures. Ainsi, selon un mode de réalisation représenté sur la figure 1 , un système selon l'invention comprend un serveur 2 hébergeant un premier module de préparation des données Prep, destiné à transformer les données natives Nat dans une structure de données optimisée OD par rapport aux données numériques natives, selon un traitement automatisé utilisant un chargement partiel en mémoire vive, et un second mod u le de rend u R1 ou R2, respectivement avec et sans carte graphique. Ces modules R1 et R2 opèrent le rendu sur la base de la structure de donnée optimisée OD.
L'objectif du mécanisme de préparation des données est de réaliser u ne préparation des données le plus rapidement possible, en utilisant un traitement multitâche par lots, de façon automatique, et en réduisant le nombre de paramètres de traitement pour obtenir des données optimisées stockées de façon compactes et organisées de manière efficace.
La préparation des données fournit deux types de données DB1 et DB2 adaptées aux deux modes de rendus distincts.
Le rendu est effectué sur différents types de matériels hétérogènes, s o i t e n ré a l i s a n t u n re n d u R 1 u t i l i s a n t l e s m oye n s d ' a ccélération graphique (GPU) et le ou les processeurs génériques (CPU) dans le cas ou des moyens d'accélération graphique sont présents sur le matériel 3, constitué par exemple par un ordinateur personnel destiné à une utilisation pour des log iciels 3D, soit en rendu en utilisant uniquement le ou les processeurs génériques (CPU) d'un matériel 4 ne comprenant aucun moyen d'accélération graphique, ce type de matériel correspondant par exemple à un ordinateur de type portable destiné à des opérations de bureautique ou de consultation d'Internet.
Ces modules de rendu R1 ou R2 assurent un rendu performant, avec le meilleur niveau de détail possible. Dans tous les cas un affichage à l'écran est réalisé, cet affichage pouvant être dégradé. Le rendu utilise un chargement partiel en mémoire vive et prend en compte un budget mémoire.
Il est à noter qu'il est possible de considérer pour le module de préparation Prep de données d'autres sources de données, en utilisant un connecteur C opérant des transformations de données.
Des moyens de protection et de garantie de la confidentialité des données peuvent également être mis en place de façon optionnelle.
Par ailleurs, il est également possibilité d'utiliser d'autres moteurs de rendu (GPU/CPU) à l'aide de connecteurs C.
Les modules de préparation Prep et de rend u R1 ou R2 sont représentés sur la figure 1 de façon répartie sur différentes plateformes matérielles. Il est possible dans ce cas de mettre en place un mécanisme de réplication des données DB1 ou DB2 à destination des plateformes matérielles 3 et 4 sur lesquels sont exécutés les opérations de rendu.
De façon alternative, il est possible d'exécuter le module de rendu R1 ou R2 sur la même plateforme matérielle que le module de préparation Prep.
III. Préparation des données
Nous allons à présent décrire les étapes de préparation des données en référence aux figures 2 à 9.
La figure 2 fait apparaître à la fois un traitement des métadonnées M D et des don nées géométriques D présentent dans les données natives Nat.
L'objectif des étapes de préparation par le module de rendu Prep est d'obtenir une organisation compacte et efficace pour un rendu hors du noyau.
Ainsi , en ce qu i concerne les métadonnées MD, après une première étape EP1 de conversion des métadonnées, une étape EP2 de création d'un dictionnaire de métadonnées est effectuée de façon à séparer les métadonnées et à obtenir des couples clé K/valeur V.
Un stockage différencié est opéré. Les clés K sont injectées dans la géométrie dans une étape EP4.
Les valeurs V sont stockées hors de la géométrie en particulier dans un système de gestion de base de données (SGBD).
Ces dispositions permettent d'assurer une grande compacité des données, l'ensemble des clés K prend peu de place et peut être détaché de l'ensemble des valeurs V.
L'intérêt de cette approche est de permettre une interaction par métadonnées (groupement, mettre en évidence/cacher des objets, identification des objets).
Les clés K sont i njectées dans la géométrie D sous forme d'attributs de données non géométrique.
Par exemple, ces clés peuvent être introduites dans les données des triangles en tant qu'attributs de sommets, ou encore dans les données de voxel, en tant que champ de bits dans la charge du voxel.
Les clés sont générées de manière automatique. Dans une étape EP3, il est possible de réaliser une réplication de la base de données des métadonnées sur un poste client 3, 4, afin de faciliter le déploiement des métadonnées sur le poste client.
Il est en fait possible de prévoir deux types de bases de métadonnées :
- un système de gestion de base de données (SGBD) multi utilisateur déployé sur un serveur, par exemple sur le serveur sur lequel est exécuté le module de préparation Prep, ce SGBD étant attaqué par plusieurs sous serveurs de préparation distants, et
- un SGBD mono utilisateur léger, par exemple sur un poste client 3, 4 ou s'exécute un module de rendu R1 ou R2.
L'étape de réplication correspond à une extraction des données nécessaire du premier SGBD pour générer une base plus petite dans le second SGBD.
En ce qui concerne les données géométriques, une première étape EP5 de conversion à partir des données natives est réalisée. Les données géométriques D sont des représentations numériques constituées par des maillages, surfaces implicites, ou d'autres représentations par exemple de type brep. L'étape de conversion consiste à transformer, en utilisant des connecteurs ou adapteurs les représentations diverses des données natives Nat en une représentation commune attendue par les étapes ultérieures du procédé, en assurant une fidélité maximale des données
Une fois les données converties dans un format commun, une étape de métavoxelisation EP6 est réalisée.
La métavoxelisation consiste à associer les éléments de donnée numérique D, constitués notamment par des triangles, aux cubes d'une grille régulière divisant l'espace dans lequel est plongée la scène 3D dont le rendu doit être effectué.
La métavoxelisation comprend une étape préliminaire de calcul des boîtes englobantes (BE) des objets de la scène. Ces boîtes sont alignées sur les axes d'un repère AABB (Axis Aligned Bounding Box) (Figure 3). Ces boîtes englobantes sont calculées dans le repère local de l'objet, et la position de l'objet dans le repère global de la scène est importée depuis les métadonnées.
Cette étape préliminaire est réalisée de préférence lors de l'importation des métadonnées. Par la suite, les boîtes englobantes sont exprimées dans le repère commun ou global.
La métavoxelisation comprend ensuite :
- une étape de précalcul consistant à tester l'intersection des boîtes englobantes des objets de la scène avec les cellules de la grilles, et
- une étape consistant à tester les intersections entre les triangles des objets dont la boîte englobante forme une intersection avec ladite cellule.
Ces dispositions permettent de diminuer fortement le temps de calcul de la métavoxelisation par rapport à un test naïf d'intersection de tous les triangles des objets de la scène avec l'ensemble des cellules de la grille.
Ainsi, le test naïf occasionne un coût de calcul proportionnel à n*p*k où n représente le nombre de cellules de la grille, p le nombre d'objets de la scène et k le nombre de triangles moyen par objet, alors que la méthode en d e ux sou s-éta pes d écrites ci-dessus occasionne un coût de calcul proportionnel à n*p+m*k où m représente le nombre de cellules contenant potentiellement des éléments de la géométrie, ce nombre étant en général bien inférieur à n.
Lors de l'étape de précalcul, une liste Lcell associe chaque élément de géométrie à un ensemble de cellules de la grille contenant de la géométrie. Cette liste est constituée en insérant pour chaque objet de la scène, les cellules de la grille présentant une intersection avec sa boîte englobante. Une fois la liste Lcell construite, un parcours de cette liste permet de construire, une liste Lgeom qui pour chaque cellule, associe les objets présentant une intersection ladite cellule est constituée.
A titre d'exemple, la figure 3 représente quatre cellules CG0, CG1 ,
CG2, CG3 de la grille et deux objets O1 et O2. La boîte englobante BE(O1 ) de l'objet O1 présente une intersection avec les cellules CGO et CG2, et la boîte englobante BE(O2) présente une intersection avec les cellules CGO et CG1 . Dans cet exemple, on obtient dans ce cas :
Lcell[O1 ]={CG0, CG2}
Lcell[O2]={CG0, CG1 }
Les listes Lgeom sont ensuite construites en croisant les valeurs des listes Lcell.
Lgeom[CG0]={O1 ,O2}
Lgeom[CG1 ]={O2}
Lgeom[CG2]={O1 } Lgeom[CG3]={}
Lors de l'étape suivante de gridding, les intersections des triangles des objets avec les cellules de la grille sont réalisées. Dans un mode de réalisation particulier, pour chaque cellule CG, la liste des objets intersectés Lgeom est considérée, et pour chaque objet de cette liste, un test d'intersection est réalisé pour chaque triangle T de l'objet afin de déterminer si le centre de gravité de ce triangle est compris dans la cellule CG.
Cette disposition basée sur l'utilisation de la position du centre de gravité permet une résolution univoque de l'appartenance entre une cellule et un triangle : un triangle appartient à une seule cellule de la grille.
A titre d'exemple, la figure 4 représente deux cellules CGO et CG1 , et un objet s'entendant sur ces deux cellules et comprenant deux triangles T1 et T2.
Le centre de gravité du triangle T1 étant situé dans la cellule CGO et le triangle T2 étant situé dans la cellule CG1 , le triangle T1 est rattaché à la cellule CGO alors que le triangle T2 est rattaché à la cellule CG1 , alors que ces deux triangles présentent chacun des intersections avec les deux cellules.
Des métavoxels, c'est-à-dire des sous-ensembles de données 3D appartenant à une cellule de la grille, constitués notamment par des triangles, sont ainsi constitués.
Chaque métavoxel comprend un ensemble de triangles, les triangles intersectés des objets sont stockés de manière contigue en conservant une métadonnée M correspondant à un identifiant de l'objet pour les différencier.
Une liste de triplets d'indices et une liste de sommets stockés de manière contigues sont ainsi obtenues.
Dans le cas du premier type de rendu utilisant une accélération graphique par GPU, ces dispositions permettent :
- un chargement depuis le stockage sur disque (HDD) vers la mémoire vive (RAM) du microprocesseur (CPU), puis dans la mémoire vidéo ou VRAM du processeur graphique (GPU) ; et
- un rendu rapide sur GPU en minimisant les changements d'états OpenGL et en s'adaptant à l'architecture des GPU).
Ainsi, dans le cas représenté sur la figure 5 d'un premier objet O1 comprenant deux triangles, le premier triangle étant formé comprenant trois sommets correspondant aux positions P0, P1 , P2, le second triangle étant formé par les sommets correspondant aux positions P1 , P2 et P3, et d'un deuxième objet 02 comprenant un triangle formé par les sommets aux positions P4, P5, P6, la liste des sommets LS et la liste des indices Ll peuvent être stockées de la façon suivante :
LS = {(PO; M(O1 )) (P1 ;M(O1 )) (P2;M(O1 )) (P3;M(O1 )) (P4; M(O2)
(P5;M(O2)) (P6;M(O2))}.
Ll = (0;1 ;2) (1 ;2;3) (4;5;6)...
Da n s l eq u el M co rres pon d à u n e m étadonnée représentant l'identifiant d'un objet, P une position, et les valeurs des indices dans la liste des indices correspondent aux rangs des sommets dans la liste LS.
II est à noter que dans le cas du premier type de rendu R1 utilisant une accélération g raph ique, les clés K des métadonnées permettent de retrouver les valeurs dans le dictionnaire de métadonnées et de différencier les éléments d'un même métavoxel appartenant à des objets différents.
Le stockage peut être réal isé en tant qu'attribut de sommet. Un sommet peut contenir en effet des données de :
- Position : xyz sur 3*16bits
- Normale : xyz sur 3*16bits
- des attributs métadonnée sous formes de clés sur 3*8 bits - des coordonnées de textures
- d'autres attributs génériques
Le fait de stocker les métadonnées dans la géométrie permet un gain mémoire car le stockage peut être réalisé dans la mémoire vidéo (VRAM). II n'est donc pas nécessa ire de stocker les clés K da ns l a mémo i re vive (RAM). Les données D de géométrie peuvent alors être supprimées de la mémoire vive (RAM) une fois chargées dans la mémoire vidéo (VRAM).
Après l'étape de métavoxel isation, les étapes ultérieures de préparation sont distinctes pour la préparation destinée au premier mode de rendu (avec GPU) et au second mode de rendu (sans GPU). 1. Préparation des données - étapes relatives au premier mode de rendu
Dans le cas d'une préparation pour le premier mode de rendu, une étape EP7 de simplification est réalisée.
Lors de l'étape de simplification, le but est de générer pour les données géométriques contenues dans chaque métavoxel plusieurs niveaux de détail (LOD) de façon à pouvoir afficher ces données géométriques natives avec une mémoire vive (RAM) limitée.
En particulier, cinq niveaux de détails peuvent être générés et stockés pour chaque métavoxel :
- un niveau nO correspondant aux données natives, en utilisant simplement le résultat de l'étape de métavoxel isation et le stockage contigu de ces données ;
- un niveau n1 dans lequel un évidage de la géométrie est réalisé : seule la surface externe est conservée (Figure 6);
- un niveau n2 utilisant une simplification légère assurée par la fusion de sommets (Figure 7);
- un niveau n3 utilisant une simplification importante également assurée par la fusion de sommets ;
- un dernier niveau n4 util isant des « imposteurs », c'est-à-dire 6 vues du contenu du métavoxel, sous formes de textures plaquées sur des quadrilatères (Figure 8).
Les niveaux n1 à n4 sont détaillés ci-dessous.
Dans le cas d'un évidage correspondant au niveau n1 , comme cela est représenté d e façon schématiq ue su r l a fig u re 6, seule l'enveloppe externe O1 ext des objets est conservée, les éléments intérieurs 01 int étant supprimés. A cet effet, quatre étapes sont mises en œuvre : dans un premier temps, une discrétisation des éléments de géométrie dans une grille de voxels est réalisée. Puis un remplissage des voxels extérieurs Vext est réalisé. On déterm ine ensu ite la frontière, c'est-à-dire des voxels à la zone limite rempl ie/non remplie. Le maillage évidé est ensuite généré en extrayant les triangles appartenant à cette frontière.
Dans le cas d'une simplification correspondant au niveau n2 ou n3, l'objectif est de simplifier l'enveloppe externe des objets. Deux étapes sont mises en œuvres, comme illustré sur la figure 7 : le maillage est plongé dans une grille G, pour réduire le temps de calcul, puis, pour chaque cube de la grille et chaque sommet s, dans ce cube, la d istance entre deux som mets est comparée à une limite d déterminée. Si la distance est inférieure à d, les sommets sont fusionnés. Dans la figure les ensembles de sommets {s1 ;s2} et {s3;s4} sont fusionnés. Il est à noter que la limite d peut être fixée automatiquement par exemple comme une fraction du rayon de la sphère englobante du maillage. Dans l e cas d ' u ne gén ération d'imposteurs correspondant au niveau n4, un rendu est réalisé pour un nombre limité nv de points de vue, par exemple 6 (devant, derrière, haut, bas, gauche, droite), puis le résultat du rendu est capturé dans une texture, puis l'imposteur I est généré sous forme de nv quadrilatères sur lesquels sont plaqués les nv textures.
Suite à l'étape de simplification, une étape de concaténation et de compression EP8 est réalisée. L'objectif de ce cette étape est de regrouper les données en un ou pl usieurs méta-fichiers, de faciliter le déploiement des données, et notamment d'accélérer la copie de lors de l'installation, et d'accélérer le rendu en optimisant les transferts entre le disque (HDD) et la mémo ire vive ( RAM ) pa r u n e uti l isation d u cache d isq ue (H DD) et u n mécanisme de transfert entre le disque (H DD) et la mémoire vive (RAM) du système d'exploitation.
Dans le cas du premier mode de rendu (avec GPU), le stockage est réalisé sous forme de deux ensembles, comme cela est illustré sur la figure 9 : un premier ensemble comprenant des index, et un second ensemble comprenant les données.
Chaque index mvID est un identifiant unique qui correspond à un métavoxel et permet d'accéder à celui-ci. Dans le premier ensemble, la taille décompressée T de ch aq u e m étavoxel est également stockée, pour les différents niveaux de détails, de façon à pouvoir prévoir le budget mémoire lors du rendu, ce qui sera détaillé ultérieurement.
Les données sont stockées dans un second ensemble de manière séquentielle, séparées en bloc Bk de la taille d'un cluster d'un multiple de 512
Les données sont stockées compressées et sont décompressées à la volée.
Les données contiennent les Métavoxels stockés par niveaux de détail nO, n1 , n2, n3, n4.
2. Préparation des données - étapes relatives au second mode de rendu
Nous allons à présent décrire les étapes ultérieures à la métavoxel isation EP6 relatives à la préparation d'un rendu selon le second mode de rendu (sans GPU).
Suite à l'étape de métavoxel isation, une étape de voxelisation EP9 est réalisée. Ainsi , pou r chaque métavoxel obtenu lors de l'étape EP6, une subdivision en métavoxel de niveau supérieur de détail est réalisée. Chaque métavoxel de niveau supérieur de détail peut être à son tour divisé en un ensemble de métavoxel de niveau supérieur de détail.
Comme cela est représenté sur la figure 1 1 , une grille régulière récursive est utilisée qui comporte plusieurs niveaux de définitions de grille régulière.
Un métavoxel d'un niveau donné de la grille correspond à une subdivision d'un métavoxel de niveau inférieur de détail.
A titre d'exemple, comme cela est représenté sur la figure 1 1 pour chaque métavoxel de niveau i, une grille peut être définie dans laquelle le métavoxel de niveau i est divisé ni fois par axe, par exemple avec ni=16.
Les éléments de volume ou voxels obtenus de niveau i peuvent à leur tour constituer un métavoxel de niveau i+1 pour lequel un nouveau niveau de grille peut être définie en procédant à une nouvelle division ni+1 fois par axe avec par exemple ni+1 =16.
Comme cela est décrit sur la figure 1 1 , pour faciliter le parcours dans la grille de chaque niveau, des divisions intermédiaires ou un niveau intermédiaire i.O peuvent être définis. Ces niveaux permettent de définir une première subdivision intermédiaire du métavoxel niO division par axe, avec par exemple ni0=4, puis une seconde subdivision intermédiaire ni1 , avec par exemple ni1 =4 de façon à obtenir un voxel de niveau i, Le nombre de subdivision sur chaque axe ni est égal au produit de ni0*ni1 .
Il est bien entendu possible de choisir des nombres de division ni différents pour chaque niveau de grille.
La figure 12 illustre la structure d'un identifiant unique de métavoxel métavoxelID, dans le cas ou quatre niveaux de grille sont utilisés.
Les quatre niveaux correspondent à :
- un niveau de base correspondant à la division réalisée dans le cadre de la métavoxélisation commune au premier mode de rendu (utilisant un
GPU) et second mode de rendu (sans GPU), et
- trois niveaux spécifiques au second mode de rendu.
Cet identifiant comprend :
- une information depth sur la profondeur du métavoxel considéré dans les niveaux de profondeur de la grille régulière ; - des informations de position dans les différents niveaux de grille et en particulier :
- l'identifiant ID Scène du métavoxel du niveau de base correspondant à la position selon trois axes XYZ par rapport au repère global de la scène, cette position étant repérée par des indices de positionnement dans la grille (position identique au métavoxel correspondant de l'étape EP6);
- la position Pos 0, Pos 1 , Pos. 2, dans les niveaux de grille spécifiques au rendu 2D.
Il est à noter que les positions Pos 0, Pos 1 , Pos. 2 peuvent être décomposés en deux indices LvlOiD et LvM iD correspondant aux niveaux intermédiaires de la grille à chaque niveau.
Comme cela est illustré par la figure 12, l'identifiant Méta Voxel ID est un identifiant unique, utilisé pour tous les métavoxels des différents niveaux de profondeur de la grille régulière.
Bien entendu, un nombre de niveaux de grille supérieur ou inférieur à quatre peut être utilisé.
Nous allons à présent détailler la réalisation de la voxelisation permettant de définir pour chaque métavoxel de chaque niveau de la grille des représentations sous forme de voxel ou cube, de plan ou de primitive ou encore de « niveau virtuel ».
Un voxel correspond à la présence ou non de matière : au rendu, ce volume peut faire l'objet de plusieurs représentations.
Selon une première possibilité, les voxels pleins peuvent être représentés par des cubes.
Pour améliorer la qualité de rendu, il est possible d'associer une normale à chaque voxel qui permet de simuler une surface pour le calcul de l'éclairage.
Da n s l e cas d ' u n « niveau virtuel », le volume du voxel est représenté par une subdivision en des cubes correspondant à une subdivision du volume du voxel en 2 sur chaque axe. Ces cubes peuvent être pleins ou vides. Par exemple 8 cubes sont définis. Ces cubes partagent une même définition de la normale qui correspond à la normale du voxel père.
L'utilisation de ces cubes permet de raffiner la représentation en volume sans nécessiter un niveau de grille régulière supplémentaire.
II est également possible d'utiliser une représentation par un plan et une normale. Pou r amél iorer l'aspect, le cube peut être remplacé par un ensemble fini de configurations géométriques encore appelées primitives.
Nous allons à présent détailler des méthodes de calcul des représentations en volume à partir des données 3D représentées sous formes de triangles.
Dans le cas d'une représentation en cube du voxel, il suffit d'identifier les voxels contenant de la matière et de les représenter par un voxel plein.
Pour calculer une normale correspondante, il est possible par exemple de calculer une normale correspondant à la moyenne des normales des triangles contenus dans le volume destinés à être représentés par le voxel.
Comme cela est représenté sur la figure 15, dans le cas d'une représentation par un plan et une normale, la première étape consiste à calculer une normale représentant le mieux le voxel, par exemple comme une normale moyenne sur les triangles de la géométrie, puis à projeter tous les sommets A de la géométrie en un point B sur la droite définit par la normale et le centre du voxel.
Il est ensuite possible de définir deux positions extrêmes des projections Min et Max sur la droite et de définir un premier et un second plan perpendiculaires à la normale passant par ces deux positions extrêmes. La représentation du voxel correspond aux deux plans ainsi définis.
Dans le cas de l'utilisation de primitives, il est possible, comme cela est illustré sur la figure 16, de définir par exemple :
(A) - Un premier type de primitives à partir de 6 normales correspondant à des plans coupant le cube en diagonale, définissant ainsi 12 demi-cubes prismatiques en tant que primitives de part et d'autre de chaque plan,
(B) - Un second type de primitives à partir de 3 normales correspondant à des plans coupant le cube en 2, parallèlement à ses côtés, définissant ainsi 6 pavés en tant que primitives et
(C) - Un troisième type de primitives à partir de 8 subdivisions du cube en tant que cubes présentant une arête de dimension divisée par 2, ce qui correspond à la définition de 8 primitives.
Pour les deux premiers types de primitives, il est possible de déterminer si une primitive est utilisable en : - réalisant une projection des vertex de la géométrie sur la normale, puis
- à déterminer si tous les points projetés se trouvent dans le même demi espace.
Si tous les points projetés sont dans le même demi-espace, alors la forme peut être retenue. Il est possible de retenir arbitrairement la première qui satisfait le critère.
Si aucune des primitives des deux premiers types ne convient, un test est réalisé pour identifier si tous les triangles sont contenus dans un seul cube présentant une arête correspondant à la moitié du voxel conformément au troisième type de primitive.
Si aucune des primitives ne convient, on utilise la représentation standard d'un voxel sous forme d'un cube plein de la taille du voxel.
La voxélisation est réalisée de façon indépendante par les différents threads ou processus pour chaque métavoxel dans la grille à plusieurs niveaux, en partant de la racine et en parcourant l'arborescence des voxels.
La voxelisation étant réalisée de façon indépendante pour les métavoxels, et les résultats étant stockés de manière séquentielle, une seconde étape de réorganisation permet de rassembler de façon contiguë les données relatives à l'ensemble des voxels fils d'un même voxel père, ce qui correspond à une réorganisation des voxels. Ces dispositions permettent d'améliorer les performances lors du rendu, et notamment les interrogations de la grille régulière récursive.
Pour chaque métavoxel, une fusion est opérée avec les métavoxels voisins. La voxelisation est effectuée sur ce groupe de métavoxels, de façon indépendante en utilisant une approche multiprocessus et multithreads pour la voxelisation.
Cette disposition a pour objet d'éviter des trous éventuels lors de la voxelisation causés par le fait que des triangles se trouvant sur la frontière entre deux métavoxels sont affectés de façon univoque à l'un de ces deux métavoxels en fonction de la position de leur centre de gravité, comme cela a été décrit précédemment.
Le stockage est réalisé sous forme de deux ensembles, comme cela est illustré sur la figure 10 : un premier ensemble comprenant des index, et un second ensemble comprenant les données. Le but est d'optimiser les transferts vers le disque (HDD) par un stockage séquentiel mais en permettant un accès direct.
Nous avons précédemment détaillé la structure des index qui correspondent aux identifiants metavoxelID en référence à la figure 12. Nous allons à présent décrire le stockage des données.
Les données sont stockées sous forme de blocs.
Les blocs sont organisés de la façon suivante.
Les blocs comprennent un entête et des charges utiles des voxels.
L'utilisation d'un entête permet une économie d'espace de stockage et un accès direct aux données.
La structure de stockage des données relatives aux métavoxels est illustrée sur la figure 13a.
L'entête comporte une table d'index IndexTbl de mémoire vive
(RAM).
Cette table d'index permet d'accéder à l'ensemble de la charge utile dans le cache (RAM) alors qu'elle elle est stockée de façon non contiguë dans ce cache. Le cache RAM est alloué par le procédé pour réaliser le chargement des charges utiles de voxels.
La table d'index comprend :
- un identifiant ID qui correspond au métavoxelID détaillé en référence à la figure 12 ;
- un index vers le premier bloc de mémoire du méta-voxel père ;
- un index de fichier vers le père, en vue de restaurer celui-ci dans la charge utile ;
- des pointeurs vers les autres blocs relatifs au même métavoxel ;
- le nombre de ces blocs ;
- un compteur d'usage correspondant aux nombre de threads ayant accès aux données à un instant donné, afin d'identifier si celle-ci peuvent être ou non supprimées du cache ;
- un remplissage permettant de s'assurer que les champs de charge utile ne s'étendent pas sur deux blocs.
L'entête comporte également un masque de présence qui permet d'indiquer pour chaque voxel si celui-ci est vide ou plein, et ceci pour chaque niveau de profondeur de la grille. Par exemple, le masque peut comprendre un 0 pour indiquer un voxel vide et un 1 pour un voxel plein (c'est-à-dire contenant de la géométrie). Ce masque de présence permet de simplifier les calculs d'intersection. Il n'y ainsi pas besoin d'accéder aux données relatives à chaque voxel.
Selon un aspect particulier, un premier masque de présence Msk Voxel i.O est stocké pour des voxel représentant une subdivision au niveau intermédiaire de chaque métavoxel comme cela a été détaillé en référence à la figure 1 1 , et un ensemble de masque de présence Msk i .1 est stocké pour chacun de ces voxels de niveau intermédiaire. Une information de décalage est également stockée qui permet de retrouver facilement la charge utile du voxel.
Ces dispositions permettent de faciliter encore les calculs d' intersection de rayon , en permettant de tester dans un premier temps l'intersection avec un voxel intermédiaire, puis de ne tester les intersections qu'avec les voxels compris dans les voxels intermédiaires pour lesquels une intersection est détectée.
La figures 1 3b permet de décrire la structure des masques et des décalages dans un exemple simplifié en considérant des masques de 4 bits pour les masques i.O et i.1 .
En supposant que le masque i .O présente le contenu su ivant :
[1 ,0,1 ,1 ], une table est constituée qui stocke pour chaque entrée du masque i.O un masque i.1 et un décalage correspondant au nombre de voxels pleins répertoriée avant le voxel intermédiaire i .0 courant.
Ainsi, comme cela est décrit sur la figure 13b pour la première ligne, un masque i.1 est stocké avec par exemple le contenu suivant [0,1 , 0, 1 ] qui comprend donc deux voxel pleins. Un offset ou décalage nul est stocké car il s'agit du premier voxel intermédiaire i.O traité.
La seconde ligne correspond à une entrée à 0 dans le masque i.O.
Dans ces conditions, aucun masque i.1 n'est stockée l'information de décalage n'est pas stockée non plus.
La troisième ligne correspond à une entrée à 1 dans le masque i.O. un masque i.1 est stocké avec par exemple le contenu suivant [1 ,0, 1 , 1 ] qui comprend donc trois voxels pleins. Un offset ou décalage de 2 fois la taille d'une charge utile PL d'un voxel PISize, par exemple de 1 28bit, est stocké correspondant aux deux voxels pleins de la première ligne.
La quatrième ligne correspond à une entrée à 1 dans le masque i.O. un masque i.1 est stocké avec par exemple le contenu suivant [0,0, 1 , 1 ] qui comprend donc deux voxels pleins. Un offset ou décalage de (2+3) fois la taille d'une charge utile d'un voxel PISize est stocké correspondant aux deux voxels pleins de la prem ière l igne et aux trois voxels pleins de la troisième ligne.
Pour chaque ligne, le décalage correspond à la taille de la charge utile PL d'un voxel multiplié par le nombre cumulé de voxels plein dans les lignes précédentes.
Ainsi, pour calculer l'emplacement de la charge utile PL du voxel correspondant au bit 3 du mask i.1 de la ligne 3 :
- on vérifie que le bit 3 du mask i.O soit à 1 (si non le voxel que l'on considère est vide) ;
- on récupère ensuite le mask i.1 de la ligne 3 (Lsb[0,0,1 ,1 ]Msb),
- on compte le nombre de voxels pleins (nbVoxPlein) avant le voxel considéré. Ici nbVoxPlein vaut 1 car seul le bit 2 est à 1 avant le bit 3.
Comme cela est illustré sur la figure 13c, La position de la charge utile considérée est donnée par la relation suivante.
Offset + nbVoxPlein*PISize = (2+3)*PISize + nbVoxPlein*PISize =
5*PISize+1 *PISize.
La structure de stockage des données relative aux métavoxels comporte en outre un champ de donnée qui comprend les charges utiles des voxels pleins.
Les charges utiles des voxels sont stockées séquentiellement. La charge utile comprend la description des voxels.
Selon un mode de mise en œuvre, quatre types de charge utiles de voxel sont possibles :
- Les nœuds (Node), voxel intermédiaire qui pointe vers des voxels d'un niveau plus élevé dans l'arborescence;
- Les fe u i l l es pouva n t être : soit une représentation par plan/normale, soit une primitive, de type cube ou autre.
La structure des données de charge utile correspondant à ces différents types est illustrée à la figure 14.
Le stockage d'une charge utile comprend :
- une zone utile « Free to Use »,
- une donnée Klm représentant la taille des données décompressées des enfants de cet éléments, la donnée Klm comprenant le nombre K de sous-voxels pleins dans ce voxel, et
- un type de charge (Nœud, primitive, plan/normale, niveau virtuel). Il est à donner que la donnée Klm permet de faire la prévision du budget mémoire.
Dans le cas d'un nœud, la zone utile comprend un pointeur dans le cache vers un métavoxel de niveau plus défini supérieur, et du remplissage.
Dans le cas d'une primitive, la zone utile comprend :
- la taille compressée du métavoxel de niveau plus défini,
- un index de fichier sur le disque vers le métavoxel de niveau plus défini,
- un espace de stockage pour des identifiants de groupes et d'objets,
- un identifiant du type de primitive, et
- un identifiant d'une normale obtenue à partir de la géométrie native qui est représentée par la primitive. Des valeurs de normales possibles discrétisées prédéfinies sont stockées dans un tableau, L'identifiant de la normale correspond à une entrée dans ce tableau.
Dans le cas d'un plan/ d'une normale, la zone utile comprend :
- la taille compressée du métavoxel de niveau inférieur,
- un index de fichier sur le disque vers le métavoxel de niveau inférieur - un espace de stockage pour des identifiants de groupes et d'objets,
- les coordonnées de la normale.
Dans le cas d'un « niveau virtuel », les données suivantes sont stockées :
- la taille compressée du métavoxel de niveau inférieur,
- un index de fichier sur le disque vers le métavoxel de niveau inférieur - un espace de stockage pour des identifiants de groupes et d'objets,
- un masque de présence indiquant si chacun des cubes compris dans le niveau virtuel est plein ou vide,
- les coordonnées de la normale.
A titre d'exemple, les normales peuvent être discrétisées sur 14 bits, les primitives possibles sont au nombre de 2Λ5 et les normales possibles discrétisées pour cette primitive au nombre de 2 .
Les ch a rg es ut i l es son t stoc kées co m pressées et sont décompressées à la volée lors du chargement.
Comme nous l'avons vu précédemment les éléments géométriques de la scène 3D sont regroupés en objets, les objets appartenant à des groupes. Nous allons à présent décrire en référence à la figure 17, la prise en compte de l'appartenance des éléments géométriques à un objet ou à un groupe d'objet dans le cadre de la préparation d'un rendu selon le second mode de rendu.
Lors de la voxelisation, les données géométriques appartenant aux objets et groupes d'objets sont concaténées ou fusionnées pour chaque métavoxel pour être ensuite représentée par une seule primitive ou un plan. Pour chaque métavoxel , des métadonnées sont conservées permettant d'identifier les éléments appartenant aux différents groupes et aux différents objets.
En particulier, on définit :
- des identifiants ou clefs KO d'objet ou de combinaison d'objets, ainsi que
- des identifiants ou clefs KG de groupe d'objet et de combinaison de groupes d'objets.
Les identifiants ou clés KG KO sont fractionnées et stockées de façon réparties sur les différents niveaux de grille, afin de prendre en compte la taille limitée de charge utile par voxel.
Ces métadonnées sont stockées dans des tables de la façon suivante :
- une table IDGrTbl des identifiants de groupes KG et/ou de combinaison de groupes est stockée pour tous les métavoxels.
- une table IDObjTbl des identifiants ou clés KO d'objets ou de combinaison d'objets est stockée au niveau des métavoxels de plus faible niveau de détail.
Lors de la sélection d'un élément de la scène, il est possible à partir du métavoxel de plus haut niveau de détail d'obtenir une information sur les groupes d'objets présents dans ledit métavoxel, puis de croiser cette information avec les identifiants des objets stockées au niveau du métavoxel de niveau de détail le plus faible pour limiter la sélection d'objets possibles.
La figure 17 illustre un exemple de groupes et d'objets contenus dans ces groupes. Dans ce cas deux groupes d'objet Gn et Gr2 sont définis comprenant respectivement des objets On, Ο12, Ο13, Οι4, Ο15, Ο16, et Ο21 , 022- Un métavoxel MV0 de niveau 0 comprend les objets On, Ο12 et Ο21. Les tables IDGrTbl et IDOTbl pour ce métavoxel MV0 sont alors reproduites ci- dessous :
IDGrTbl (MV0) : KG1 -> {Gn}
KG2 -> {Gr2}
KG3 -> {KG1 , KG2}
IDOTbl (MVo) :
KO1 -> {On}
KO2-> {Ο12}
KO3-> {Ο21}
Pour le métavoxel MV1 de niveau 1 , seuls des identifiants de groupes d'objets ou de combinaisons de groupes d'objets sont stockés. Ainsi, pour le métavoxel MV1 , seule la clé KG1 sera stockée car le métavoxel MV1 ne contient que des objets du groupe Gn.
IV. Etapes de Rendu
Nous allons à présent détailler la réalisation du rendu selon les deux modes de réalisation évoqués précédemment.
1. Etapes de rendu - Premier mode de rendu
Comme nous l'avons vu précédemment, le premier mode de rendu R1 utilise les moyens d'accélération graphique (GPU) et le ou les processeurs génériques (CPU)
L'objectif étant de réaliser un rendu le plus rapidement possible en termes de temps de chargement et de fréquence d'affichage, tout en respectant le budget mémoire vive (RAM) et vidéo (VRAM) et en maximisant la qualité de rendu correspondant aux niveaux de détail.
Les étapes de rendu sont représentées sur la figure 18. En ce qui concerne l'utilisation des métadonnées, comme nous l'avons vu précédemment, un dictionnaire couples (clé K, valeur V) a été constitué, que les clés ont été injectées dans la géométrie, et que les valeurs stockées dans un SGDB.
Le traitement d'une requête relative aux métadonnées est traité de la façon suivante.
La clé K est récupérée depuis l'affichage 3D. Ainsi, lors d'une requête de l'utilisateur ER1_0, pour une métadonnée correspondant à un point de l'image, le GPU procède à un rendu dans un mode d'affichage qui permet d'associer une clé à un code couleur. Le tampon de rendu correspondant est alors récupéré sur le CPU qui identifie les clés K dans ce tampon.
Le dictionnaire est alors interrogé à l'aide de la clé K dans une étape ER1_9.
En réponse à la requête ER1_10, un retour visuel sur l'affichage 3D peut être effectué dans une étape ER1_8, par exemple sous forme de mise en évidence ou d'occultation d'un objet, ou encore d'affichage des propriétés, de filtrage des données.
En ce qui concerne la réalisation du rendu en lui-même, il apparaît qu'en réponse à une mise à jour de la caméra dans une étape ER1_1 suite à une interaction utilisateur ER1_0, les chargements des données entre le disque, la mémoire vive (RAM) puis la RAM et la mémoire vidéo (VRAM) sont réalisés.
En ce qui concerne l'ordonnancement de ces tâches, il apparaît que deux tâches de chargement doivent être réalisées, à savoir :
- un chargement entre le disque (HDD) et la mémoire vive (RAM) ; et
- un chargement entre la mémoire vive (RAM) et la mémoire vidéo (VRAM) ;
Dans certaines configurations, par exemple des configurations utilisant OpenGL 2.0, il n'est pas possible de multithreader le chargement entre la RAM et la VRAM. Ainsi, afin de réduire le temps de chargement, les deux tâches de chargement (H DD->RAM et RAM->VRAM) sont séparées et entrelacées. Le chargement HDD->RAM s'effectue sur un thread secondaire et le chargement RAM->VRAM s'effectue sur un thread principal.
La synchronisation entre les deux threads de chargement s'effectue à l'aide de queue de chargement et de déchargement. Ces queues permettent de fragmenter les tâches de chargement afin d'éviter une latence trop longue. Ainsi, plutôt que de charger n metavoxels, p.q métavoxels sont chargés où p est le nombre de metavoxels chargés lors d'une demande et q=n/l, I étant la taille de la queue.
Le traitement des queues de déchargement est également découpé en deux parties avec :
- un traitement des requêtes de mise à jour/chargement sur un thread secondaire, et
- un traitement effectif de la requête sur un thread principal Les requêtes de chargement ou de mise à jour sont déterminées en réal isant dans une étape ER1_2 un calcul de l'ensemble des métavoxels visibles depuis la caméra puis en calculant les niveaux de détail pour chacun de ces métavoxels dans une étape ER1_3.
L'objectif de l'étape ER1 _2 de calcul des métavoxels visibles 1 1 a pour objectif d'éliminer le plus possible de métavoxels non visibles, c'est-à-dire, comme cela est illustré sur la figure 19 : les métavoxels 10 non contenus dans le frustum de la caméra, représentés hachurés et les métavoxels 12 cachés par d'autres métavoxels, représentés remplis par des pointillés.
En particulier, ce calcul est réalisé en 4 étapes selon un algorithme de type décrit dans le document « Dean Sekulic Chapter 29. Efficient Occlusion Culling, GPU Gems, Nvidia », à savoir :
- Un calcul de l'ensemble des éléments occludeurs inclus dans le frustum caméra ;
- un rendu à une première image t des métavoxels constituant des éléments occludeurs sous forme d'imposteurs I ;
- à l'image t+1 une requête d'occlusion est effectuée sur la base de la première image afin de déterminer si un élément occludeur est visible par rapport aux autres éléments occludeurs du point de vue de la caméra ;
- à l'image t+2 : le chargement des métavoxels ignore les métavoxels cachés.
Différencier les étapes de rendu des éléments occludeurs des requêtes d'occlusion permet de lisser la latence introduite par ces requêtes d'occlusions.
L'étape ER1_3 de calcul des niveaux de détail a pour objectif de déterminer le n iveau de détail de chaque métavoxel pour obtenir le meilleur affichage et respecter les contraintes mémoires.
Ce calcul est réalisé en simulant un chargement des métavoxels sur un ensemble de secteurs correspondant à des zones à une distance données de la caméra, puis, pour chaque secteur, à déterminer son niveau de détail, puis à cumuler le budget mémoire correspondant en utilisant la liste des tailles T décompressées.
Si le budget mémoire n'est pas dépassé alors le meilleur niveau de détail est choisi, sinon un niveau de détail plus bas est choisi.
Ce fonctionnement est illustré sur la figure 20 dans lequel cinq secteurs S0 à S4 sont illustrés. Les métavoxels M hachurés disposés dans les secteurs S3 et S4 devront être chargés avec un niveau de détail bas car la limite de budget est dépassée.
Sur la base des étapes ER1_2 de détermination des métavoxels visibles et ER1_3 de calcul des niveaux de détail, les étapes :
- ER1_4 de demandes de mise à jour de la queue de chargement,
- ER1_5 de demande de mise à jour de la queue de déchargement,
- ER1_6 de chargement effectif et
- ER1_7 de déchargement effectif sont effectuées.
L'objectif de ces étapes est d'éviter une latence trop longue en fragmentant les tâches de chargement et déchargement.
Ainsi, Le thread HDD->RAM effectue une requête de mise à jour. Toutes les t secondes, le thread secondaire RAM->VRAM vérifie les demandes de requêtes de mise à jour des queues de chargement et de déchargement. Si une requête est rencontrée, les métavoxels sont effectivement chargés du HDD vers RAM.
Pour réduire le temps de chargement global, le niveau de détail le plus bas, constitué notamment par les imposteurs I est toujours chargé en mémoire vidéo VRAM.
La mise à jour de la queue de déchargement consiste à décharger des métavoxels de la mémoire vidéo VRAM.
La queue de chargement permet de :
- charger un métavoxel depuis le disque HDD vers la mémoire vive
RAM, puis
- dans un second temps, de charger le métavoxel vers la mémoire vidéo VRAM et de le décharger de la mémoire vive RAM.
De plus, les doublons de stockage RAMA/RAM sont évités grâce aux structures de données choisies et en particulier au stockage des métadonnées dans les données géométriques, il n'est pas nécessaire de conserver la géométrie en RAM.
Le calcul des priorités entre les chargements/déchargements a pour objectif de limiter la latence de chargement, de maximiser les gains de mémoires et d'éviter les trous lors de l'affichage.
Pour limiter la latence, il convient de privilégier les transitions faisant gagner un niveau de détail . Pour maximiser les gains en mémoire, il convient de privilégier les déchargements aux chargements et les transitions vers un niveau de détail plus bas. Pour éviter d'obtenir des trous lors de l'affichage, il convient de ne décharger un ancien metavoxel seulement si un metavoxel vient d'être chargé à la place.
Ainsi l'ordre de priorité, à titre d'exemple peut être le suivant :
a- les transitions de tous n iveau (nO à n3) comprenant de la géométrie vers un niveau d'imposteur (n4)
b- les transitions d'un niveau d'imposteur (n4) vers un niveau comprenant de la géométrie avec un niveau de détail important (nO à n2)
c- les transitions d'un niveau de détail avec géométrie vers un niveau de détail plus important (n2 vers n1 ou n3 vers n2) ;
d- les transitions d'un niveau de détail avec géométrie vers un niveau de détail inférieur avec géométrie (n1 vers n2 ou n2 vers n3) ;
e - les transitions d'un niveau d'imposteur (n4) vers un niveau avec géométrie de faible niveau de détail (n3).
2. Etapes de rendu - Second mode de rendu
Nous allons à présent détailler la réalisation du second mode de rendu. Comme nous l'avons vu précédemment, ce second mode de rendu utilise uniquement le ou les processeurs génériques (CPU), sans utiliser de moyens d'accélération graphique.
L'objectif de ce second mode est de réaliser un rendu le plus rapidement possible en termes de temps de chargement et de fréquence d'affichage en respectant le budget de mémoire vive RAM disponible, en maximisant la qualité de rendu, sans carte vidéo fournissant une accélération 3D, c'est-à-dire sans moyen dédié de rendu de triangles et sans mémoire vidéo (VRAM) disponible.
Les étapes de rendu sont représentées sur la figure 21 .
En ce qui concerne l'utilisation des métadonnées, comme nous l'avons vu précédemment, un dictionnaire couples (clé K, valeur V) a été constitué, que les clés ont été injectées dans la charge utile des voxels, et que les valeurs ont été stockées dans un SGDB.
Le traitement d'une requête relative aux métadonnées est réalisé de la façon suivante, similaire à celle du premier mode de rendu.
La clé K est récupérée depuis l'affichage 3D. Ainsi, lors d'une requête de l'utilisateur ER2_0, pour une métadonnée correspondant à un point de l'image, le CPU peut obtenir, lors du rendu, la valeur de la clé stockée dans les données géométriques pour le point considéré. Le dictionnaire est alors interrogé à l'aide de la clé K dans une étape ER2_9.
En réponse à la requête ER2_9, un retour visuel sur l'affichage 3D peut être effectué dans une étape ER2_5, par exemple sous forme de mise en évidence ou d'occultation d'un objet, ou encore d'affichage des propriétés, de filtrage des données.
En ce qui concerne la réalisation du rendu en lui-même, il apparaît qu'en réponse à une mise à jour de la caméra dans une étape ER2_1 suite à une interaction utilisateur ER2_0, un chargement des données entre le disque et la mémoire vive (RAM) est effectué et un rendu est réalisé.
En ce qui concerne l'ordonnancement de ces tâches, il apparaît qu'au moins deux threads de chargement et de rendu sont entrelacés.
Comme cela est représenté sur la figure 21 , 3 niveaux de caches peuvent être utilisés, afin de limiter la consommation mémoire et maximiser la qualité du rendu.
Un premier niveau de cache correspond aux métavoxels et contient les voxels de la grille de niveau 0. Tous les voxels de niveau 0 sont stockés dans ce cache dès le départ du rendu.
Un second niveau de cache correspond aux métavoxels qui contiennent les voxels de la grille de niveau supérieur au niveau 0. Le mode de chargement consiste à charger les voxels fils des voxels G0 jusqu'à saturation de la mémoire. Le mode de chargement dans ce premier cache est le suivant : suite à un calcul des métavoxels2D visibles, les voxels G0 sont chargés jusqu'à saturation de la mémoire, en en chargeant le maximum possible en fonction du point de vue et du déplacement.
Un troisième niveau de cache est un buffer circulaire destiné à charger les voxels correspondant au niveau de profondeur de la grille récursive la plus élevée. Les voxels à charger sont déterminés à l'aide d'un lancer de rayon, lors de la traversée de la grille régulière récursive. Ce troisième cache est un buffer sous forme de buffer circulaire. Lorsqu'un élément du cache est utilisé, son indice de réutilisation est augmenté. Le choix des éléments à remplacer dans le cache correspond à l'élément le moins utilisé dans le cache. Ce troisième cache est utilisé pour un mode de rendu spécifique HD+ qui sera détaillé ultérieurement.
Comme cela est illustré sur la figure 21 , suite à la mise à jour de la caméra, une étape ER_2_6 de détermination du mode de rendu est réalisée, afin de déterminer un mode de rendu permettant d'afficher le plus rapidement avec la meilleure qualité possible.
En particulier, 4 modes d'affichage sont définis.
Dans un premier mode à basse définition ou SD, des voxels de la grille de niveau 0 et éventuellement de niveau supérieur sont affichés. Des requêtes de chargement des métavoxels de la grille de niveau supérieur à 0 sont lancées et les métavoxels correspondants sont chargés au fur et à mesure que la caméra se déplace. Pour éviter la latence liée au chargement des métavoxels de niveau supérieur à 0, le rendu est effectué avec les métavoxels de niveau supérieur à 0 qui sont disponibles suite à leur chargement et le reste des métavoxels visibles conserve le niveau 0.
La définition de la fenêtre de rendu est diminuée, par exemple en étant d ivisée par deux. Ce mode est activé lors d'un déplacement de la caméra;
Dans un second mode à moyenne définition ou MD activé dès que le mouvement de la position de la caméra est arrêté, un affichage à la définition de la fenêtre de rendu est réalisé. Les métavoxels de niveau de grille supérieur à 0 chargés pendant le déplacement dans le mode SD sont pris en compte. Le reste des métavoxels visible conserve le niveau G0. Un recalcul de l'image à la dimension de la fenêtre est réalisé.
Si la position de la caméra reste inchangée, lorsque l'ensemble des requêtes de chargement est réalisée, un nouveau rendu est réalisé selon un troisième mode HD avec les métavoxels de niveau 0 et de niveau supérieur chargés selon des niveaux de priorité jusqu'à saturation du second cache.
Ces trois premiers modes utilisent le premier et le second cache décrits précédemment.
Sur requête de l'utilisateur, un quatrième type de rendu HD+ peut être réalisé, à la définition de la fenêtre de rendu. Dans ce cas, tous les métavoxels de niveau de détail le plus élevé, visibles depuis la caméra sont chargés. Afin de pouvoir tous les considérer, ils sont chargés de manière circulaire dans le troisième cache.
La figure 22 illustre les relations et les activations des différents modes de rendu . A partir d'un état « inactif », si un événement « en mvt » correspondant à un mouvement de caméra est détecté, une transition vers un état de calcul d'une image SD « calcul image SD » est déclenchée. A partir de cet état, une transition vers un état « inactif en mouvement » est déclenchée lorsque l'image SD est prête. Une transition en retour vers l'état « calcul image SD » est déclenchée si les paramètres de caméra sont mod ifiés « MAJ Caméra » . A partir des états « calcul image SD » ou « Inactif en mvt », une transition est déclenchée vers un état de calcul d'une image MD lors de la détection d'une fin de mouvement de caméra « fin de mvt ».A partir de cet état un transistion vers un état intemédiaire lorsque le calcul de l'image MD est achevé. Dans cet état intermédiaire, une transition vers l'état « Inactif » est déclenchée si une requête de chargement « RC (requête de chargement) en cours » est en cours et une transition vers un état de calcul d'une image en mode H D « Calcul image HD » si aucune requête de chargement n'est en cours « Pas de RC en cours ».
A partir de l'état « Inactif », une transition vers l'état « Calcul image HD » est générée si l'ensemble des requêtes de chargement ont été traitées « Aucune RC en cours ».
Sur requête d'un utilisateur, un calcul d'une image en mode HD+ peut être déclenché dans un état « calcul image HD+ », sous réserve qu'une image HD ait déjà été calculée.
A partir des états « calcul image MD » , « calcul image HD » ou « calcul image HD+ », une transition est générée vers un état d'arrêt des requêtes de chargement et de vid age d u cache « Arrêt et effacement du Cache » sur une détection d'une reprise du mouvement « En mvt ». Une fois l'opération de vidange du cache réal isée, une transition vers l'état « Calcul image SD » est déclenchée.
De façon optionnelle, un état de calcul sans affichage d'une image SD peut être prévu, afin d'optimiser le calcul des objets visibles par un test d'occlusion (voxels cachés par d'autres voxels). Un rendu SD permet en effet de construire l'ensemble des métavoxels V1 visibles depuis la caméra, seuls ces voxels étant ensuite chargés lors du calcul d'une image MD ou HD.
En ce qui concerne l'étape ER2_4 de rendu des voxels, ce rendu peut notamment être réalisé par la méthode dite du 3D-DDA, illustrée sur la figure 23.
Chaque élément de la grille est examiné le long du rayon. La traversée de la grille est récursive. Nous prenons ci-dessous un exemple en référence à la figure 21 et en se limitant à deux niveau de grille. Bien entendu, des niveaux de grille supplémentaires peuvent être utilisés. Tant que le rayon n'a pas rencontré d'élément au niveau 0 de la grille, le curseur avance le long du rayon. Lorsqu'un élément plein au niveau 0 est rencontré par le rayon, comme par exemple le voxel V0 sur la figure 21 , le rayon parcours les éléments de niveau 1 contenus dans le métavoxel vO. Tant que le rayon n'a pas rencontré d'élément 1 de la grille dans le métavoxel, le curseur avance le long du rayon. Lorsque un élément plein est rencontré, comme par exemple le voxel v3 de la figure 21 : la traversée s'arrête, l'éclairage est calculé, le cache de voxels est mis à jour.
V. Relevés de performance
La figure 24 reprend des données de relevé de performances sur une plateforme de tests constituée par un ordinateur grand public, dont l'unité centrale comprend un processeur 4 cœurs (Intel Core2Quad Q6600, 2.40 Ghz), une mémoire vive (RAM) de 2 Go, une carte graphique: NVidia GeForce 8800 GTX avec une mémoire vidéo (VRAM) de 768 Mo dont la capacité maximale effective est de 30 millions de triangles @ 10fps.
Les relevés de performance ont été effectués sur la base du rendu avec GPU de deux modèles:
- un premier modèle Md1 comprenant 35Go de données, 30 milliards de triangles, 600000 objets et 30 groupes; et
- un second modèle Md2 comprenant 10Go de données, 40 millions de triangles, 20000 objets et 7 groupes.
Selon des variantes de l'invention, dans la phase de préparation des données, d'autres mécanismes de simplification du maillage peuvent être utilisés. Il est également possible de considérer d'autres sources de données à l'aide de connecteurs.
Dans la phase de rendu des données, d'autres mécanismes peuvent être également utilisés pour afficher des données en très basse qualité (imposteurs/voxels...), des voxels rendus par CPU/GPU, et/ou utilisant un rendu hybride mettant en œuvre le CPU/GPU (CPU/CPU ou GPU/GPU)
II est possible d'utiliser d'autres moteurs de rendu (GPU/CPU) à l'aide de connecteurs.

Claims

REVENDICATIONS
1 . Procédé de rendu d'une scène virtuelle en trois dimensions comprenant:
une première phase de préparation de données comprenant au moins une étape de regroupement de données de la scène dans une structure de données (OD) correspondant à une division spatiale de la scène en une grille régulière (GO) de façon à former des métavoxels, les données numériques étant stockées dans la structure de donnée optimisée (OD) sous différents niveaux de détail (nO, n1 , n2, n3, n4) par métavoxel, les différents niveaux correspondant à des simplifications géométriques, et
une seconde phase de rendu temps réel utilisant la structure de données géométriques (OD) pour le rendu d'au moins une image comprenant une étape de détermination des niveaux de détails à utiliser pour chaque métavoxel prenant en compte une limite de budget en mémoire d'un ordinateur sur lequel est exécuté au moins la phase de rendu et effectuant une simulation de l'occupation en mémoire des métavoxels à charger suivant leur niveau de détail (nO, n1 , n2, n3, n4).
2. Procédé selon la revendication 1 , dans lequel la métavoxelisation comprend : u ne étape de pré calcul consistant à tester l'intersection des boîtes englobantes (BE) des objets de la scène avec les cellules de la grilles, et une étape de test des intersections entre les triangles des objets dont la boîte englobante forme une intersection avec ladite cellule.
3. Procédé selon l'une des revendications précédentes, dans lequel l'utilisation de la position du centre de gravité permet une résolution univoque de l'appartenance entre une cellule et un triangle.
4. Procédé selon l'une des revendications précédentes, dans lequel les données de la scène sont stockées sous forme d'un premier ensemble comprenant un identifiant unique d'un métavoxel (mvID) et une liste des tailles (T) à l'état décompressé de chaque métavoxel selon les différents niveaux de détails (nO, n1 , n2, n3, n4); et
d'un second ensemble comprenant les données géométriques relatives à chaque métavoxel, notamment de manière séquentielle, dans différents niveaux de détails (nO, n1 , n2, n3, n4).
5. Procédé selon l'une des revendications précédentes, dans lequel le calcul des niveaux de détail (nO, n1 , n2, n3, n4) à utiliser pour chaque métavoxel visible depuis une position de caméra pour laquelle le rendu est effectué est réalisé,
en prenant en compte un ensemble de secteurs (S0, S1 , Sd) correspondant à des zones à une distance donnée de la position de caméra, en attribuant un niveau de détail à l'ensemble des métavoxels présents dans un même secteur, les niveaux de détails étant décroissants avec l'éloignement de la position de la caméra de façon à adapter un espace mémoire simulé nécessaire au chargement des métavoxels sur l'ensemble des secteurs à une limite de budget mémoire disponible.
6. Procédé selon la revendication 4 et selon la revendication 5, dans lequel la simulation du budget mémoire est réalisée en utilisant la liste des tailles (T) décompressées.
7. Procédé selon l'une des revendications précédentes, dans lequel le niveau de détail le plus bas (n4), constitué notamment par des imposteurs (I) est toujours chargé dans la mémoire d'un ordinateur sur lequel est exécuté au moins la phase de rendu, et de préférence dans une mémoire vidéo (VRAM) de moyens d'accélération graphique (GPU).
8. Procédé selon l'une des revendications précédentes, dans lequel les données sont stockées compressées, décompressées à la volée.
9. Procédé selon l'une des revendications précédentes, comprenant une première tâche de chargement des données géométriques de métavoxels à partir d'une mémoire de masse, par exemple un disque dur (HDD) et une mémoire vive (RAM) d'un ordinateur sur lequel est exécuté au moins la phase de rendu, et une seconde tâche de chargement des données géométriques de métavoxels entre la mémoire vive (RAM) de l'ordinateur sur lequel est exécuté au moins la phase de rendu et une mémoire vidéo (VRAM) de moyens d'accélération graphique, ces deux tâches de chargement étant séparées et entrelacées, la première tâche étant prise en charge par un thread secondaire s'effectuant sur un microprocesseur de l'ordinateur et la seconde tâche étant prise charge par un thread principal, la synchronisation entre les deux tâches étant effectuée à l'aide d'une queue de chargement et d'une queue de déchargement.
10. Procédé selon l'une des revendications précédentes, dans lequel un calcul des priorités entre les chargements/déchargements est réalisé, ce calcul privilégiant tout ou partie des transitions suivantes: les transitions faisant gagner un niveau de détail, les déchargements aux chargements, et les transitions vers un niveau de détail plus bas, et l'absence de trous lors de l'affichage.
1 1 . Procédé selon l'une des revendications précédentes, dans lequel l'étape de rendu comprend un calcul de l'ensemble des métavoxels potentiellement visibles depuis une position de caméra pour laquelle le rendu est effectué la détermination des métavoxels occultés (cachés par d'autres métavoxels) étant effectué à l'aide d'une étape de rendu intermédiaire basée sur l'utilisation d'imposteurs pris en compte dans le calcul de visibilité pour le rendu d'une image ultérieure au rendu de l'image courante.
PCT/FR2012/050783 2011-04-12 2012-04-11 Procede et systeme de rendu d'une scene virtuelle en trois dimensions WO2012140360A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1153172A FR2974213B1 (fr) 2011-04-12 2011-04-12 Procede et systeme de rendu d'une scene virtuelle en trois dimensions
FR1153172 2011-04-12

Publications (1)

Publication Number Publication Date
WO2012140360A1 true WO2012140360A1 (fr) 2012-10-18

Family

ID=46147490

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/050783 WO2012140360A1 (fr) 2011-04-12 2012-04-11 Procede et systeme de rendu d'une scene virtuelle en trois dimensions

Country Status (2)

Country Link
FR (1) FR2974213B1 (fr)
WO (1) WO2012140360A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109448136A (zh) * 2018-09-29 2019-03-08 北京航空航天大学 一种基于感兴趣区域的虚拟场景浏览方法
CN109785424A (zh) * 2018-12-11 2019-05-21 成都四方伟业软件股份有限公司 一种三维异步模型粒子边界处理方法
CN110458934A (zh) * 2013-03-14 2019-11-15 想象技术有限公司 用隐式几何体进行3d图形渲染
CN115174963A (zh) * 2022-09-08 2022-10-11 阿里巴巴（中国）有限公司 视频生成方法、视频帧生成方法、装置及电子设备
CN117076226A (zh) * 2023-10-16 2023-11-17 北京麟卓信息科技有限公司 一种基于图像纹理差异的图形系统渲染正确性验证方法
US11861787B2 (en) 2013-03-14 2024-01-02 Imagination Technologies Limited 3-D graphics rendering with implicit geometry
CN117611472A (zh) * 2024-01-24 2024-02-27 四川物通科技有限公司 一种用于元宇宙空间与云渲染的融合方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998000811A1 (fr) * 1996-06-28 1998-01-08 Resolution Technologies, Inc. Procede et appareil de conception assistee par ordinateur operant par transparence
GB2356113A (en) * 1999-11-02 2001-05-09 Elixir Studios Ltd Selecting a graphical representation of an object based on the viewing distance of the object
WO2001048697A1 (fr) * 1999-12-23 2001-07-05 Intel Corporation Procede de simplification de scene statique hierarchique et gestion de polygones dans un modele 3d
US6933946B1 (en) 2003-05-07 2005-08-23 At&T Corp. Method for out-of core rendering of large 3D models

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998000811A1 (fr) * 1996-06-28 1998-01-08 Resolution Technologies, Inc. Procede et appareil de conception assistee par ordinateur operant par transparence
GB2356113A (en) * 1999-11-02 2001-05-09 Elixir Studios Ltd Selecting a graphical representation of an object based on the viewing distance of the object
WO2001048697A1 (fr) * 1999-12-23 2001-07-05 Intel Corporation Procede de simplification de scene statique hierarchique et gestion de polygones dans un modele 3d
US6933946B1 (en) 2003-05-07 2005-08-23 At&T Corp. Method for out-of core rendering of large 3D models

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CHAMBERLAIN B ET AL: "Fast rendering of complex environments using a spatial hierarchy", PROCEEDINGS. GRAPHICS INTERFACE, 22 May 1996 (1996-05-22), pages 132 - 141, XP002163546 *
CIGNONI P ET AL: "Adaptive tetrapuzzles: efficient out-of-core construction and visualization of gigantic multiresolution polygonal models", ACM TRANSACTIONS ON GRAPHICS, vol. 23, no. 3, August 2004 (2004-08-01), ACM USA, pages 796 - 803, XP002665708, ISSN: 0730-0301 *
DECORO C ET AL: "XFastMesh: fast view-dependent meshing from external memory", VIS 2002. IEEE VISUALIZATION 2002. PROCEEDINGS., 27 October 2002 (2002-10-27) - 1 November 2002 (2002-11-01), BOSTON, MA, pages 363 - 370, XP031212986, ISBN: 978-0-7803-7498-0 *
LUEBKE D ET AL: "Level of detail for 3D Graphics, Section 2 - Mesh Simplification", 1 January 2003, LEVEL OF DETAIL FOR 3D GRAPHICS; [THE MORGAN KAUFMANN SERIES IN COMPUTER GRAPHICS AND GEOMETRIC MODELING], MORGAN KAUFMANN, NL, ISBN: 978-1-55860-838-2, pages: 19 - 46, XP002665707 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110458934A (zh) * 2013-03-14 2019-11-15 想象技术有限公司 用隐式几何体进行3d图形渲染
CN110458934B (zh) * 2013-03-14 2023-12-19 想象技术有限公司 用隐式几何体进行3d图形渲染
US11861787B2 (en) 2013-03-14 2024-01-02 Imagination Technologies Limited 3-D graphics rendering with implicit geometry
CN109448136A (zh) * 2018-09-29 2019-03-08 北京航空航天大学 一种基于感兴趣区域的虚拟场景浏览方法
CN109448136B (zh) * 2018-09-29 2023-03-28 北京航空航天大学 一种基于感兴趣区域的虚拟场景浏览方法
CN109785424A (zh) * 2018-12-11 2019-05-21 成都四方伟业软件股份有限公司 一种三维异步模型粒子边界处理方法
CN115174963A (zh) * 2022-09-08 2022-10-11 阿里巴巴（中国）有限公司 视频生成方法、视频帧生成方法、装置及电子设备
CN117076226A (zh) * 2023-10-16 2023-11-17 北京麟卓信息科技有限公司 一种基于图像纹理差异的图形系统渲染正确性验证方法
CN117076226B (zh) * 2023-10-16 2023-12-29 北京麟卓信息科技有限公司 一种基于图像纹理差异的图形系统渲染正确性验证方法
CN117611472A (zh) * 2024-01-24 2024-02-27 四川物通科技有限公司 一种用于元宇宙空间与云渲染的融合方法
CN117611472B (zh) * 2024-01-24 2024-04-09 四川物通科技有限公司 一种用于元宇宙空间与云渲染的融合方法

Also Published As

Publication number Publication date
FR2974213A1 (fr) 2012-10-19
FR2974213B1 (fr) 2013-05-24

Similar Documents

Publication Publication Date Title
WO2012140360A1 (fr) Procede et systeme de rendu d'une scene virtuelle en trois dimensions
Wimmer et al. Instant Points: Fast Rendering of Unprocessed Point Clouds.
Yoon et al. Real-time massive model rendering
Cignoni et al. Adaptive tetrapuzzles: efficient out-of-core construction and visualization of gigantic multiresolution polygonal models
Schütz et al. Fast Out‐of‐Core Octree Generation for Massive Point Clouds
EP1982310B1 (fr) Procede de synthese d'une image virtuelle par lancer de faisceaux
WO2012140361A1 (fr) Procédé et système de rendu d'une scène virtuelle en trois dimensions
CN103093499B (zh) 一种适用于网络传输的城市三维模型数据组织方法
Richter et al. Out-of-core real-time visualization of massive 3D point clouds
Yoon et al. Quick-VDR: Out-of-core view-dependent rendering of gigantic models
FR2852128A1 (fr) Procede pour la gestion de la representation d'au moins une scene 3d modelisee.
Steinberger et al. On‐the‐fly generation and rendering of infinite cities on the GPU
Cignoni et al. Selective refinement queries for volume visualization of unstructured tetrahedral meshes
FR2999005A1 (fr) Procede de rendu d'un terrain stocke dans une base de donnees massive
CN101119485A (zh) 一种基于特征保留的三维模型递进传输方法
US10482629B2 (en) System, method and computer program product for automatic optimization of 3D textured models for network transfer and real-time rendering
CN103268221A (zh) 一种基于web技术的气象数据体三维显示方法及装置
WO2006079712A1 (fr) Procédé et dispositif de sélection du niveau de détail par calcul de visibilité pour des scènes 3d multi-niveaux de détail
EP2504816B1 (fr) Procede d'estimation de diffusion de la lumiere
FR2964775A1 (fr) Procede d'estimation de l'occultation dans un environnement virtuel
Guthe et al. Efficient view-dependent out-of-core visualization
FR2974215A1 (fr) Procede et systeme de rendu d'une scene virtuelle en trois dimensions
Tariq et al. Instanced model simplification using combined geometric and appearance-related metric
Kang et al. An efficient simplification and real-time rendering algorithm for large-scale terrain
CN116152039B (zh) 图像渲染的方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12722771

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12722771

Country of ref document: EP

Kind code of ref document: A1