GDATA Documentation, Material IDs etc.

SDK supports Prepar3D’s philosophy of an open development architecture and encourages third parties to bring new innovations with improved add-ons and training content.
Post Reply
seanmcleod
Posts: 55
Joined: Thu Mar 24, 2011 1:18 pm

GDATA Documentation, Material IDs etc.

Post by seanmcleod »

I've been battling to find any real documentation on the GDATA sensor.

So far I've only come across snippets from postings on this forum.

Mentioning that the R channel is a grey scale value. Is this grey scale value simply the standard grey scale value of the visual RGB value for the pixel?

Mentioning that the G channel is a material ID. However the list of material IDs in the post seem to be out of date when I take a look at some sample pixel values from the Radar Camera. Where can we find the current up to date list of material IDs? I've searched the whole of the SDK installation directory without any luck in terms of finding such a list/enums.

Mentioning that the B channel is the dot product between the surface normal and eye direction. I assume simply scaling [0, 1] to [0, 255]?

Is the GDATA sensor type documented in the SDK somewhere? Either somewhere in the SDK documentation or even in some header file?
User avatar
Beau Hollis
Lockheed Martin
Posts: 2452
Joined: Wed Oct 06, 2010 3:25 pm

Re: GDATA Documentation, Material IDs etc.

Post by Beau Hollis »

When you sample the texture you’ll get a value from 0-1.0. To compare material IDs you need to multiply by 255.

The object type passed into the shaders comes from an internal enum:
RENDER_OBJ_TYPE_DEFAULT = 0,
RENDER_OBJ_TYPE_SKY,
RENDER_OBJ_TYPE_STARS,
RENDER_OBJ_TYPE_CLOUDS,
RENDER_OBJ_TYPE_TERRAIN,
RENDER_OBJ_TYPE_GROUND_ELEMENT,
RENDER_OBJ_TYPE_EXTRUSION,
RENDER_OBJ_TYPE_CRATER,
RENDER_OBJ_TYPE_WATER,
RENDER_OBJ_TYPE_VEGETATION,
RENDER_OBJ_TYPE_AUTOGEN_BUILDINGS,
RENDER_OBJ_TYPE_POLY,
RENDER_OBJ_TYPE_ROADS,
RENDER_OBJ_TYPE_TAXIWAY,
RENDER_OBJ_TYPE_APRON,
RENDER_OBJ_TYPE_RUNWAY,
RENDER_OBJ_TYPE_MODELS,

RENDER_OBJ_TYPE_TRAFFIC,
RENDER_OBJ_TYPE_USER_AIRCRAFT,
RENDER_OBJ_TYPE_ATTACHED_TO_USER_AIRCRAFT,
RENDER_OBJ_TYPE_LENS_FLARE,
RENDER_OBJ_TYPE_RUNWAY_MARKINGS,
RENDER_OBJ_TYPE_TAXIWAY_MARKINGS,
RENDER_OBJ_TYPE_HELIPADS,

RENDER_OBJ_TYPE_RUNWAY_LIGHTS,
RENDER_OBJ_TYPE_PARTICLE,
RENDER_OBJ_TYPE_SPRITE,
RENDER_OBJ_TYPE_GENERIC_MODEL,
RENDER_OBJ_TYPE_PYLON,

All the items in bold are set to 0 in the general/pbr shader. We did this to simplify the radar which mostly just cares about land, water, and asphalt/concrete. If we go back and revisit this, we might remove this code from our material shader and update the radar shader to do this comparison instead so that the original object type isn’t lost. That said, this list was originally used to determine z-bias so its not broken into category based on the physical material properties the way you might want. Using a combination of metalic and roughness to pack this channel with reflectivity instead of IDs might have been better in hindsight. As is, terrain, water, vegetation, and the group of things set to default are your best bet for classification.

RadarProjection.hlsl is the only one we ship that uses the standard gdata texture.

With the updates for weather radar, clouds can also render into gdata but they write:
Red: 0
Green: 1.0 (material id 255)
Blue: Precipitation Level
Alpha: Cloud transparency

The weather radar SDK sample, and the weather radar map post process (PsGDataWeatherRadarMain in Colorizer.hlsl) give examples of how you can use this info.

Since we ship our shaders in plain text, you can find all the special overrides for gdata by searching for SHD_GDATA. Most shaders that support it call into the ComputeGeometryData utility function which is in IRSim.h in the shaders folder.

The basic encoding scheme is this:
float fresnel = 1 - dot(normalWS, eyeDirectionWS);
float fObjectType = (float)objectType / 255.0f;
return float4(GrayscaleRGB(color.rgb),fObjectType,fresnel,1);
Beau Hollis
Prepar3D Software Architect
seanmcleod
Posts: 55
Joined: Thu Mar 24, 2011 1:18 pm

Re: GDATA Documentation, Material IDs etc.

Post by seanmcleod »

Thanks Beau.
Using a combination of metalic and roughness to pack this channel with reflectivity instead of IDs might have been better in hindsight.
Yep, ideally for certain sensor type calculations having a reflectivity value, plus the existing dot-product/fresnel value plus then pulling in the depth value from the depth texture would make things easier.
Post Reply