Up to now I've covered some techniques for measuring and rasterizing the pixels of the voronoi cell geometry. The problem with some of these techniques, however, experienced as of first hand or sensed immediately are as follows:
1. Blind pixel by pixel iteration requires a point in geometry test. That is sensing where sequentially ordered sets are chosen in the global sense for iterative point choosing cycles. This point in geometry test is often more cumbersome, since a measure is needed that relates such pixel to the coordinate space of any containing geometric body.
2. Pixel by pixel iteration, whatever sequence is chosen in the process, is often going to be slower relative to pre computed geometry (that is where the points in such geometry have already been applied), already rastered (meaning the points are pre computed in such geometry).
Workarounds relative to point 1:
First it seems if we could have a sensing mechanism for choosing the points in the geometry first while avoiding the points that are outside the geometry first. We would accelerate the rasterizing problem here. So, why not iterate rays from off known coordinates in such geometry.
For instance, one ray trace raster iterative solution:
1. An iterator is constructed on the set of nodes.
2. The iterated node is the starting basis for the ray trace constructions.
3. We construct 4 rays for sweeping the set of geometric points. Two rays are parallel and orthogonal to the other two rays, and take up the direction of the basis vectors for such coordinate system (that is, in the direction of x, or y respectively in two dimensions). The x horizontal ray iterator is the control point for resetting the point of origin of the vertical ray on a post iteration cycle.
4. Fortune's method used computes rapidly the base geometry for our given cell polygon, we should have the vertices and edges handy for the Voronoi node cell's polygon that the ray's occupy.
5. We can use a sense to nearest edge construction of any ray's position by having pre computed x-y boundaries for such. Computed a nearest edge boundary is shown by diagram in a previous post with the 3 gon example. In any n-gon case, we can describe a set of nested triangles (we call this nTri) for such nearest edge boundary radiating from centroid of the voronoi cell (call this Cv) to vertex (the edges generated from two neighboring vertices sharing such edge generate the triangle of nTri). Procedurally, however, the method exists, whether we use coordinate map boundaries position testing to the nearest y and x to a triangle in nTri or using say vector direction angle with upper and lower boundaries given for any triangle of nTri. Ideally such maps are well suited to rapidly convergence of a nearest edge, otherwise relative to a more blind test approach which would involve distance measuring to all edges of the voronoi cell.
6. With nearest edge found from the previous step, we can compute the shortest distance to such edge, and then having a paired scale parameter (the overall height of such nTri triangle).
Another possibility for faster rasterisation/
Another method could employ upon already drawn up sets of points for a known geometry. Meaning that if we were to overlay such geometry in the Voronoi cell, then maybe we could write blocks of points at a time, as opposed to having to point by point compute these. It seems whatever method chosen we have to keep in mind the re scaling and rotation of these geometry primitives alongside a management of getting around point by point computations for scale and rotation factors. One possibility could be something like a best fit geometry choice, where one need simply input say a map key that consisted of say a rotation and scale parameter, and a precomputed geometric table were returned with already rasterized points. This would require having some data file to rely upon, and so forth. One big potential problem to this is alignment between the gradient shades (height map coordinates) and the scale parameter of the nTri triangle.
If you were new to this, maybe there is added expense for method 1, but this method obviously seems a bit easier for now, and elsewhere anyways, rasterization of the pixels does require a pixel by pixel read of data sets regardless for heightmap rasterization.
No comments:
Post a Comment