Under Appendix H of the Vulkan spec it says:
Aspect (Image):
An image may contain multiple kinds, or aspects, of data for each pixel, where each aspect is
used in a particular way by the pipeline and may be stored differently or separately from other
aspects. For example, the color components of an image format make up the color aspect of the
image, and may be used as a framebuffer color attachment. Some operations, like depth testing,
operate only on specific aspects of an image. Others operations, like image/buffer copies, only
operate on one aspect at a time.
In addition there is the type VkImageAspectFlagBits which (I think) lists the 7 possible aspects an image can have:
VK_IMAGE_ASPECT_COLOR_BIT
VK_IMAGE_ASPECT_DEPTH_BIT
VK_IMAGE_ASPECT_STENCIL_BIT
VK_IMAGE_ASPECT_METADATA_BIT
VK_IMAGE_ASPECT_PLANE_0_BIT
VK_IMAGE_ASPECT_PLANE_1_BIT
VK_IMAGE_ASPECT_PLANE_2_BIT
VkImageCreateInfo does not have an aspects field.
If I understand correctly, a given VkImage has a subset of these 7 aspects, right?
Is there a way to deduce which of the 7 aspects a VkImage has from its VkImageCreateInfo?
ie how would you write a function that returns a bit mask of which aspects an image has?
VkImageAspectFlagsBits GetImageAspects(const VkImageCreateInfo& info) { ??? }
You can mostly derive which aspects an image has from its format:
VK_IMAGE_ASPECT_COLOR_BIT refers to all R, G, B, and/or A components available in the format.
VK_IMAGE_ASPECT_DEPTH_BIT refers to D components.
VK_IMAGE_ASPECT_STENCIL_BIT refers to S components.
VK_IMAGE_ASPECT_PLANE_n_BIT refer to the planes of multi-planar formats, i.e. ones with 2PLANE or 3PLANE in their name. These aspects are mostly used in copy commands, but can also be used to create a VkImageView of an individual plane rather than the whole image.
VK_IMAGE_ASPECT_METADATA_BIT is the odd one whose presence isn't based on format. Instead, images with sparse residency (VK_IMAGE_CREATE_SPARSE_RESIDENCY_BIT) have a metadata aspect.
If an image doesn't have the components or flag corresponding to the aspect, then it doesn't have that aspect.
Related
I'm trying to draw geometry for multiple models using a single draw call. All the geometry, thusly, resizes within the same vertex/index buffers. The geometry for the different models share the same vertex format, but the vertex amounts for each model can be different.
In the vertex/fragment shaders, what's a technique that can be used to differentiate between the different models, to access their appropriate transforms/textures/etc ?
Are these static models? For traditional static batching:
You only need a single transform relative to the batch origin (position the individual models relative to the batch origin as part of the offline data packaging step).
You can batch your textures in to a single atlas (either a single 2D image with different coordinates for each object, or a texture array with a different layer for each object).
If you do it this way you don't need to different component models - they are effectively just "one large model". Which has nice performance properties ...
For more modern methods, you can try indirect draws with multiple "drawCount" values to index the settings you want. This allows variable buffer offsets and triangle counts to be used, but the rest of the state used needs to be the same.
As an alternative to texture arrays, with bindless texturing you can just programmatically select which texture to use in the shader at runtime. BUT you generally still want it to be at least warp-uniform to avoid a performance hit.
I'm following vulkan-tutorial.com and in the images portion of the tutorial it mentions layout transitions, but doesn't elaborate on what they are. I don't like to copy and paste code without knowing exactly what it does and I can't find a sufficient explanation in the tutorial or on google.
A "layout transition" is exactly what those words mean. It's when you transition the layout of an image sub-resource from one layout to another. So your question really seems to be... what is a layout?
In the Vulkan abstraction, images are composed of sub-resources. These represent distinct sections of an image which can be manipulated independently of other sections. For example, each mipmap level of a mipmapped image is a sub-resource.
At any particular time that an image sub-resource is being used by a GPU process, that sub-resource has a layout. This is part of the Vulkan abstraction of GPU operations, so exactly what it means to the GPU will vary from chip to chip.
The important part is this: layouts restrict how you can use an image sub-resource. Or more to the point, in order to use an image sub-resource in a particular way, it must be in a layout which permits that usage.
When a sub-resource is in the VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL layout, you can only perform operations which read from the sub-resource within a shader. The shader cannot write to the image, nor can the image be used as a render target.
Now, the general layout allows pretty much any use at any time while within that layout. However, this also can represent less optimal performance. Any of the more restricted layouts can make those accesses to the image more performance-friendly (depending on hardware).
So it is your job to keep track of the layout of any image sub-resources you plan to use. Now for most images, you're going to use destination transfer layout to upload to them, and then just leave them as shader read-only, because you don't generally use most images more arbitrarily. So generally, this means keeping track of render targets that you want to read from, as well as swapchain images (you have to transition them to the present layout before presenting them) and storage images.
Layout transitions typically happen as part of an explicit dependency between two operations. This makes sense; if you're uploading data to an image, and you later want to read from it, you need a dependency between the upload and the read. You may as well do the layout transition then, since the transition can modify the way the bytes of the image are stored, so you need the transfer to be done first.
The main topic I am interested in is whether it is possible to store and extract well-structured scale information from a PDF document.
[ For example, most engineering or architectural drawings printed to a PDF would be scaled down, say 1/8 in. : 1 ft. So if actually printed to paper you could measure a part of the drawing in inches and then infer the actual real-world size in feet. ]
Is there any way to programmatically look for that scale information in the PDF format? e.g., from the example above, to extract the 1/8" : 1' ratio from the PDF.
I thought this was not even possible until I came across this statement in the Adobe document Grids, guides, and measurements in PDFs:
Use Scales And Units From Document (When Present)
When enabled, measurements based on the units generated from the
original document, if present, are used. Deselect this option to
specify the units of measurements manually.
(Alternative document with same text, p. 92)
However I can find no other references that explain how this feature works. I checked in the PDF specifications (maybe too old of a version?) and it did not mention anything. But its hard to know what to search for and I'm not very familiar with PDF internals so I may simply have missed it.
A related detail is what level of the PDF this information would be stored at (if it exists at all) - I would guess per-page?
To be clear, I am absolutely not looking to scrape text from the rendered PDF. Instead, I want to find out if there is any metadata that would encode this information. The PDFs I have to deal with would have widely varying origins & contents.
If you look at the actual PDF specification (i.e. ISO 32000, part 1 or 2), you'll find a section on measurement properties.
E.g. in ISO 32000-1:
12.9 Measurement Properties
PDF documents, such as those created by CAD software, may contain graphics that are intended to represent real-world objects. Users of such documents often require information about the scale and units of measurement of the corresponding real-world objects and their relationship to units in PDF user space.
...
Beginning with PDF 1.6, such information may be stored in a measure dictionary (see Table 261). Measure dictionaries provide information about measurement units associated with a rectangular area of the document known as a viewport.
A viewport (PDF 1.6) is a rectangular region of a page. The optional VP entry in a page dictionary (see Table 30) shall specify an array of viewport dictionaries, whose entries shall be as shown in Table 260. Viewports allow different measurement scales (specified by the Measure entry) to be used in different areas of a page, if necessary.
etc. etc.
Thus, yes, you can programmatically look for that scale information in the PDF format. Beware, though, these properties are optional, so you'll find them only if the PDF producer was nice enough to provide them.
So upon seeing images from Godus I was wondering how to generate a simple, non-interactive, 2D image with different colors for different heights or layers of heights like on the picture below.
I was just thinking in terms of generating the basic layers of colors for the topography without the houses, trees objects and units. I wasn't thinking in terms of creating a graphics engine that would solve this, but a simple way to generate a flat image on the screen.
The question is two-fold:
1, What kind of data could be used for this sort of generation? I was thinking maybe ASCII art which is kind of easy to create and modify to quickly change the topography, but would be difficult to provide height information.
2, What existing frameworks, classes, methods or methodologies could be used for solving the generation after having the data ready.
Godus:
ASCII art (northern europe with ! for Norway, # for Sweden, $ for Finland and % for Russia:
(Taken from the MapBox docs: http://mapbox.com/developers/utfgrid/#map_data_as_ascii_art)
If you want to create a simple 2D, contoured image, I would try the following:
Create some height data. I'd just use a grey-scale image for that, rather than ascii. You can author basic height-maps in MS Paint, or anything similar.
Smooth the data. For example, apply a blur, or increase the resolution using a smooth filter.
Consider clamping all height data below a certain point - this represents a water level, if you want that.
Quantise the data. The more you quantise, the fewer but more obvious the contours.
Apply a false colouring, via a palette lookup. For example a : low lying areas blue, for water, then yellow, for sand, green for grass, brown for earth, grey for rock, and white for snow.
The important parts are the enlarging/smoothing filter, which creates more interesting shapes to your contours, and the quantisation which actually creates the contours themselves.
You can play with the stages of this. For example you could introduce some noise to the terrain, to make it look more natural if your source data is very clean. Or you could increase the smoothing if you want everything very rounded.
If you want to use ascii, you could just generate a bitmap directly from that, which wouldn't be tricky. The ascii you use as an example though is split up by country rather than terrain, so the false-colouring and contouring would probably do the wrong thing. You could probably use it as input to a simple terrain generator, perhaps just having a couple of chars to denote where you want land, sea, mountains, etc.
Here's a very basic example I knocked up, it's just an application of the technique I suggested. I didn't use any frameworks or libs, just a few simple image processing functions, and an height-map of Europe I found:
This question somewhat overlaps knowledge on geospatial information systems, but I think it belongs here rather than GIS.StackExchange
There are a lot of applications around that deal with GPS data with very similar objects, most of them defined by the GPX standard. These objects would be collections of routes, tracks, waypoints, and so on. Some important programs, like GoogleMaps, serialize more or less the same entities in KML format. There are a lot of other mapping applications online (ridewithgps, strava, runkeeper, to name a few) which treat this kind of data in a different way, yet allow for more or less equivalent "operations" with the data. Examples of these operations are:
Direct manipulation of tracks/trackpoints with the mouse (including drawing over a map);
Merging and splitting based on time and/or distance;
Replacing GPS-collected elevation with DEM/SRTM elevation;
Calculating properties of part of a track (total ascent, average speed, distance, time elapsed);
There are some small libraries (like GpxPy) that try to model these objects AND THEIR METHODS, in a way that would ideally allow for an encapsulated, possibly language-independent Library/API.
The fact is: this problem is around long enough to allow for a "common accepted standard" to emerge, isn't it? In the other hand, most GIS software is very professionally oriented towards geospatial analyses, topographic and cartographic applications, while the typical trip-logging and trip-planning applications seem to be more consumer-hobbyist oriented, which might explain the quite disperse way the different projects/apps treat and model the problem.
Thus considering everything said, the question is: Is there, at present or being planned, a standard way to model canonicaly, in an Object-Oriented way, the most used GPS/Tracklog entities and their canonical attributes and methods?
There is the GPX schema and it is very close to what I imagine, but it only contains objects and attributes, not methods.
Any information will be very much appreciated, thanks!!
As far as I know, there is no standard library, interface, or even set of established best practices when it comes to storing/manipulating/processing "route" data. We have put a lot of effort into these problems at Ride with GPS and I know the same could be said by the other sites that solve related problems. I wish there was a standard, and would love to work with someone on one.
GPX is OK and appears to be a sort-of standard... at least until you start processing GPX files and discover everyone has simultaneously added their own custom extensions to the format to deal with data like heart rate, cadence, power, etc. Also, there isn't a standard way of associating a route point with a track point. Your "bread crumb trail" of the route is represented as a series of trkpt elements, and course points (e.g. "turn left onto 4th street") are represented in a separate series of rtept elements. Ideally you want to associate a given course point with a specific track point, rather than just giving the course point a latitude and longitude. If your path does several loops over the same streets, it can introduce some ambiguity in where the course points should be attached along the route.
KML and Garmin's TCX format are similar to GPX, with their own pros and cons. In the end these formats really only serve the purpose of transferring the data between programs. They do not address the issue of how to represent the data in your program, or what type of operations can be performed on the data.
We store our track data as an array of objects, with keys corresponding to different attributes such as latitude, longitude, elevation, time from start, distance from start, speed, heart rate, etc. Additionally we store some metadata along the route to specify details about each section. When parsing our array of track points, we use this metadata to split a Route into a series of Segments. Segments can be split, joined, removed, attached, reversed, etc. They also encapsulate the method of trackpoint generation, whether that is by interpolating points along a straight line, or requesting a path representing directions between the endpoints. These methods allow a reasonably straightforward implementation of drag/drop editing and other common manipulations. The Route object can be used to handle operations involving multiple segments. One example is if you have a route composed of segments - some driving directions, straight lines, walking directions, whatever - and want to reverse the route. You can ask each segment to reverse itself, maintaining its settings in the process. At a higher level we use a Map class to wire up the interface, dispatch commands to the Route(s), and keep a series of snapshots or transition functions updated properly for sensible undo/redo support.
Route manipulation and generation is one of the goals. The others are aggregating summary statistics are structuring the data for efficient visualization/interaction. These problems have been solved to some degree by any system that will take in data and produce a line graph. Not exactly new territory here. One interesting characteristic of route data is that you will often have two variables to choose from for your x-axis: time from start, and distance from start. Both are monotonically increasing, and both offer useful but different interpretations of the data. Looking at the a graph of elevation with an x-axis of distance will show a bike ride going up and down a hill as symmetrical. Using an x-axis of time, the uphill portion is considerably wider. This isn't just about visualizing the data on a graph, it also translates to decisions you make when processing the data into summary statistics. Some weighted averages make sense to base off of time, some off of distance. The operations you end up wanting are min, max, weighted (based on your choice of independent var) average, the ability to filter points and perform a filtered min/max/avg (only use points where you were moving, ignore outliers, etc), different smoothing functions (to aid in calculating total elevation gain for example), a basic concept of map/reduce functionality (how much time did I spend between 20-30mph, etc), and fixed window moving averages that involve some interpolation. The latter is necessary if you want to identify your fastest 10 minutes, or 10 minutes of highest average heartrate, etc. Lastly, you're going to want an easy and efficient way to perform whatever calculations you're running on subsets of your trackpoints.
You can see an example of all of this in action here if you're interested: http://ridewithgps.com/trips/964148
The graph at the bottom can be moused over, drag-select to zoom in. The x-axis has a link to switch between distance/time. On the left sidebar at the bottom you'll see best 30 and 60 second efforts - those are done with fixed window moving averages with interpolation. On the right sidebar, click the "Metrics" tab. Drag-select to zoom in on a section on the graph, and you will see all of the metrics update to reflect your selection.
Happy to answer any questions, or work with anyone on some sort of standard or open implementation of some of these ideas.
This probably isn't quite the answer you were looking for but figured I would offer up some details about how we do things at Ride with GPS since we are not aware of any real standards like you seem to be looking for.
Thanks!
After some deeper research, I feel obligated, for the record and for the help of future people looking for this, to mention the pretty much exhaustive work on the subject done by two entities, sometimes working in conjunction: ISO and OGC.
From ISO (International Standards Organization), the "TC 211 - Geographic information/Geomatics" section pretty much contains it all.
From OGS (Open Geospatial Consortium), their Abstract Specifications are very extensive, being at the same time redundant and complimentary to ISO's.
I'm not sure it contains object methods related to the proposed application (gps track and waypoint analysis and manipulation), but for sure the core concepts contained in these documents is rather solid. UML is their schema representation of choice.
ISO 6709 "[...] specifies the representation of coordinates, including latitude and longitude, to be used in data interchange. It additionally specifies representation of horizontal point location using coordinate types other than latitude and longitude. It also specifies the representation of height and depth that can be associated with horizontal coordinates. Representation includes units of measure and coordinate order."
ISO 19107 "specifies conceptual schemas for describing the spatial characteristics of geographic features, and a set of spatial operations consistent with these schemas. It treats vector geometry and topology up to three dimensions. It defines standard spatial operations for use in access, query, management, processing, and data exchange of geographic information for spatial (geometric and topological) objects of up to three topological dimensions embedded in coordinate spaces of up to three axes."
If I find something new, I'll come back to edit this, including links when available.