Half pixel offset problem with Direct3D9 renderer

What it says on the tin: a place to discuss proposed new features.
Post Reply
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

Hello,
pixel accurate texture mapping is crucial to the application I'm working on. I'm using the Direct3D9 renderer and it appears that the annoying D3D9 feature discussed here
http://msdn.microsoft.com/en-us/library ... 85%29.aspx
is not taken into account in the Direct3D9 renderer. Consequently I have to provide my own code on top of ogre in order to achieve accurate rendering. This works when I use textures 1:1 on screen but I haven't tested it (and don't want to) when the texture is scaled. Considering that the OpenGL renderer doesn't exhibit this kind of texture offset, I think that the offset problem should be dealt with inside Direct3D9 renderer. It is noteworthy that using the OpenGL renderer for my application is not an option because I'm using a Direct3D9 based video playback plugin.

I made a sample app to illustrate the problem with bitmap textures.
http://www.violetindustries.com/temp/Og ... Offset.zip
The sample renders a 128x256 black texture with a red one-pixel edge to the top left corner of the window.
For Direct3D9 renderer, the texture has to be offset by (0.5, 0.5*aspectRatio) pixels for accurate rendering of image edges (the inclusion of window aspect ratio may have something to do with use of Rectangle2D in the sample).
For OpenGL renderer, no offset is needed.
The offset amount can be changed in createScene method.
Note: you need to provide a path to your ogre includes directory either through project settings or VC environment path settings in order to compile the app.
Note: use windowed mode as the app doesn't take keyboard input and must be closed by closing the console window.

I had to take a screenshot and verify in an image processing program using eyedropper tool that the red edges are in right place and not filtered to adjacent pixels.
I recently updated my ogre version from the old Ogre 1.4.8 version used through Mogre to Ogre 1.6 stable branch. When I was using 1.4.8, I also noticed that textures created by CreateManual have different pixel offset. I haven't tested this after updating to a recent ogre version.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

This is only relevant to screen-space alignment, and that is taken care of with compositors, as they are the only screen-space part of Ogre. If you want to do your own screen-space rendering (via Rectangle2D or anything else) without compositors, the offset is up to you (and, yes, I know how annoying it is, I have to deal all over the place with it in my deferred renderer *and* my GUI).
User avatar
SiENcE
Goblin
Posts: 231
Joined: Thu May 11, 2006 3:07 pm
Location: Berlin
Contact:

Re: Half pixel offset problem with Direct3D9 renderer

Post by SiENcE »

It is annoying and we searched this bug for half a year in our guisystem. If someone doesn't know where to start it's a pain to search.
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

Thanks for replies SiENcE and nullsquared. I was hoping that others wouldn't have been disturbed by the offset problem and that it would be possible to easily solve it in the D3D9 Renderer. Has anyone tried to solve it in the D3D9 Renderer by eg. altering texture and/or vertex transforms before rendering? Having very limited experience with D3D9 and ogre rendersystem source, I don't feel like the right person for researching this.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

juharkonen wrote:Has anyone tried to solve it in the D3D9 Renderer by eg. altering texture and/or vertex transforms before rendering? Having very limited experience with D3D9 and ogre rendersystem source, I don't feel like the right person for researching this.
Like I said, this is only a problem when rendering 2D objects that need to be pixel-perfect. It's not a bug in the D3D renderer, it's just the way D3D works when it comes to aligning texels to pixels. There's nothing to fix - normal models, etc. will render perfectly fine since they're not 2D-aligned. Therefore, if you need to render pixel-perfect 2D objects, the texel offset is up to you to perform (compositors in Ogre deal with it, however Rectangle2D does not).
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

Thank you for the clarification nullsquared. I didn't really understand your first message about screen-space alignment but now I think I got your point.
My application uses quads created with ManualObject and these meshes exhibit the pixel offset problem. If I replace them with quad meshes loaded from a .mesh file (that is, "normal models") and use them in an identical fashion, do I get rid of the offset?
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

juharkonen wrote:Thank you for the clarification nullsquared. I didn't really understand your first message about screen-space alignment but now I think I got your point.
My application uses quads created with ManualObject and these meshes exhibit the pixel offset problem. If I replace them with quad meshes loaded from a .mesh file (that is, "normal models") and use them in an identical fashion, do I get rid of the offset?
No. Look here: http://msdn.microsoft.com/en-us/library ... S.85).aspx (copy and paste the whole thing because the link parsing is broken)

When rendering 3D objects in the scene, everything will be fine. However, if you're aligning 2D objects directly to the screen, you have to be careful so that there's a 1-to-1 mapping of texels-to-pixels.
User avatar
wacom
Gnome
Posts: 350
Joined: Sun Feb 10, 2008 2:07 pm

Re: Half pixel offset problem with Direct3D9 renderer

Post by wacom »

nullsquared wrote:Look here: http://msdn.microsoft.com/en-us/library ... S.85).aspx (copy and paste the whole thing because the link parsing is broken)
Sorry, offtopic ... You could use the url-tags: http://msdn.microsoft.com/en-us/library ... S.85).aspx :D
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

wacom wrote:
nullsquared wrote:Look here: http://msdn.microsoft.com/en-us/library ... S.85).aspx (copy and paste the whole thing because the link parsing is broken)
Sorry, offtopic ... You could use the url-tags: http://msdn.microsoft.com/en-us/library ... S.85).aspx :D
Oh I didn't know :D
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

Could you describe in more detail the difference between 3D and 2D objects? I know that some ogre constructs appear 2D (eg. Rectangle2D and overlays) whereas meshes are processed in 3D space. However my impression is that the underlying graphics APIs process all this in 3D coordinates and they all become 2D after the projection transform. What is a "normal model" that is being rendered perfectly fine and why doesn't a quad count as a normal model? What if I rotate the quad just a little bit so that it is no longer perfectly aligned with the camera? Or is it just that the offset is not eliminated when rendering meshes but it is more difficult to see in a complex model with only few triangles aligned with the camera and compositors are the only ogre construct that does eliminate the offset?
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

The difference is that 3D models sample their texture based on UV coordinates on their geometry, then once the final colour is found, they are rendered/projected onto the screen. There is no 1:1 texel-to-pixel alignment.

However, with 2D object, generally you want 1:1 texel-to-pixel alignment so that each texel in the texture has a single corresponding pixel on-screen. The problem is that pixels have whole values in their centers and fractional values on the corners, but texels have whole values at the corners and fractional values in the centers. Therefore, to align the texel [0,0] (top-left corner) to a pixel, you need to have the pixel at [-0.5, -0.5] (also top-left corner) because [0, 0] in pixels would be the center of the pixel, not the top-left corner. The link I posted explains it better, look at it.

The reason OpenGL doesn't have this issue when rendering 2D pixel-perfect objects is because OpenGL pixels *and texels* have their centers at whole values, so there is no aligning to be done.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

Perhaps this image will help:
Image

Notice how D3D texels differ from pixels, while OpenGL texels do not differ from pixels. This only applies when you want to align pixels and texels - that's why 3D objects do not require the offset, since there's no 1:1 pixel:texel ratio.
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

There wasn't anything unclear in how D3D9 maps texels to pixels or in where the offset problem originates from. I'm not sure if you noticed that the msdn link you insisted me to read was already included in my first post.

If I understood correctly, you say that the difference between 2D and 3D objects is that 2D objects are aligned with camera and the user may want them be rendered pixel accurately. It's noteworthy that all textured primitives use UV coordinates independent of whether or not they are pixel-aligned with the camera. The offset is also there even when not using an 1:1 pixel-to-texel ratio because the 3D objects are projected to 2D primitives and textured using the same D3D9 texturing principles. Textured 3D objects exhibit the same pixel offset but it's not a problem because it's unnoticeable or insignificant unless the 3D objects are used to present 2D graphics.

IMO, it's inconsistent with the idea of a high-level rendering engine that application developers have to write D3D9 specific code to eliminate artifacts that originate from unlucky D3D9 texturing design. It is also inconsistent that compositors eliminate the offset but other ogre constructs don't.
My experience from software development is that almost anything is possible and it's more a question of how much work is required and how it fits to the software design used. Now the interesting question for me is what would be the simplest way to make the Direct3D9 renderer eliminate the offset for meshes.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

juharkonen wrote:There wasn't anything unclear in how D3D9 maps texels to pixels or in where the offset problem originates from. I'm not sure if you noticed that the msdn link you insisted me to read was already included in my first post.
Oh. Didn't notice :mrgreen:
If I understood correctly, you say that the difference between 2D and 3D objects is that 2D objects are aligned with camera and the user may want them be rendered pixel accurately. It's noteworthy that all textured primitives use UV coordinates independent of whether or not they are pixel-aligned with the camera. The offset is also there even when not using an 1:1 pixel-to-texel ratio because the 3D objects are projected to 2D primitives and textured using the same D3D9 texturing principles. Textured 3D objects exhibit the same pixel offset but it's not a problem because it's unnoticeable or insignificant unless the 3D objects are used to present 2D graphics.
No, the offset is not there. Texturing on 3D objects is done on triangles in 3D world space that have UV coordinates completely unrelated to the screen. Therefore, whether [0,0] is the corner of a texel or the center of a texel does not matter since it refers to the same texel. There is no 1:1 pixel:texel mapping with 3D objects since any given pixel can be made up of any amount of interpolated texels that come out to that position.
IMO, it's inconsistent with the idea of a high-level rendering engine that application developers have to write D3D9 specific code to eliminate artifacts that originate from unlucky D3D9 texturing design. It is also inconsistent that compositors eliminate the offset but other ogre constructs don't.
It's not inconsistent. The only part of Ogre that deals with 2D things like this is the compositors framework, which indeed deals with this correctly. Like I'm trying to explain to you, this is only an issue when you're aligning 2D objects 1:1 with the screen, it's not some sort of "general Direct3D problem" that Ogre needs to fix.
My experience from software development is that almost anything is possible and it's more a question of how much work is required and how it fits to the software design used. Now the interesting question for me is what would be the simplest way to make the Direct3D9 renderer eliminate the offset for meshes.
Please look at what I've said and think it over, since you're not understanding the point.
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

These are the points we seem to disagree on;
  • You claim there is a distinction between 2D and 3D objects in D3D9 and that the pixel offset exists only when using screen space coordinates but not when UV coordinates are used. This contradicts with my understanding of the inner workings of the D3D9 rendering pipeline; there are no 2D or 3D objects, just triangles that are processed in 3D but in the end transformed to screen space and texture mapped so that the half-pixel offset occurs.
  • Your claim that the offset occurs only when aligning 2D objects 1:1 with the screen contradicts with my real-world experiences. If I render a quad mesh using texture coordinates in the range [0,1], I'll get a half pixel offset on the edges. If I downscale the quad by a factor of 2, a mipmap of the texture is used and texels are again mapped to pixels so that the offset is still there. As I see it, there is no distinction between a textured screen-aligned quad or any other 3D model.
As your claims contradict with my understanding of the problem, I find it better to trust my own judgement. As we have failed to find a mutual understanding on these aspects, there is no point to continue this discussion with you.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

Re: Half pixel offset problem with Direct3D9 renderer

Post by nullsquared »

juharkonen wrote: You claim there is a distinction between 2D and 3D objects in D3D9 and that the pixel offset exists only when using screen space coordinates but not when UV coordinates are used. This contradicts with my understanding of the inner workings of the D3D9 rendering pipeline; there are no 2D or 3D objects, just triangles that are processed in 3D but in the end transformed to screen space and texture mapped so that the half-pixel offset occurs.
This is the part that you're misunderstanding. The half pixel offset occurs when you map texels to pixels because texels have [0,0] at their corner, but pixels have [0,0] at their center. Geometry will end up in the correct spot, however, texels will not. Since texturing in 3D is done on the geometry using UV coordinates that have no relation to screen coordinates, the half pixel offset does not apply here. It *only* applies if you're texture mapping a 2D object 1-to-1 onto the screen.
If I render a quad mesh using texture coordinates in the range [0,1], I'll get a half pixel offset on the edges. If I downscale the quad by a factor of 2, a mipmap of the texture is used and texels are again mapped to pixels so that the offset is still there. As I see it, there is no distinction between a textured screen-aligned quad or any other 3D model.
That is incorrect, the texture should be correctly mapped on the quad if your texture coordinates are indeed correct.
As your claims contradict with my understanding of the problem, I find it better to trust my own judgement. As we have failed to find a mutual understanding on these aspects, there is no point to continue this discussion with you.
These are not claims, they are facts, proved by both Microsoft's D3D documentation and my own experience in writing a manual 2D GUI and a manual 2D post processing framework.
marchingcubes
Kobold
Posts: 35
Joined: Sun Jul 26, 2009 10:19 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by marchingcubes »

This page has a decent explanation of the issue (with pictures, for those who have trouble comprehending things like this):

http://drilian.com/category/development/graphics/d3d9/
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: Half pixel offset problem with Direct3D9 renderer

Post by sinbad »

Just picking up on this, I'm not sure why this was particularly contentious - the half-pixel difference between D3D and GL has been a known issue for some years. If you want to deal with it when rendering, just call RenderSystem::getHorizontalTexelOffset() and RenderSystem::getVerticalTexelOffset(), and use those values to alter either your screen-aligned geometry coordinates, or alternatively your UVs, to compensate for the texel-to-pixel mapping differences.

Here's an example of what CompositorInstance does to a Rectangle2D to fix it:

Code: Select all

            RenderSystem* rs = Root::getSingleton().getRenderSystem();
            Viewport* vp = rs->_getViewport();
            Real hOffset = rs->getHorizontalTexelOffset() / (0.5 * vp->getActualWidth());
            Real vOffset = rs->getVerticalTexelOffset() / (0.5 * vp->getActualHeight());
            mRectangle->setCorners(mQuadLeft + hOffset, mQuadTop - vOffset, mQuadRight + hOffset, mQuadBottom - vOffset);
mQuadLeft etc describe a rectangle in homogenous screen coordinates ie (-1,1).

The reason this doesn't typically affect '3D' objects is that the UVs are assigned in object-space. When everything is transformed, the textures are mapped where they should be because everything goes through a consistent transform - the entire pipeline understands what the origin of a pixel / texel is, so no half-pixel offset is needed. However, if you projected a texture from the screen onto a 3D object, then you would have the same problem, because your projection has to cater for the way that the rasteriser interprets the UVs. In this case you'd have to apply the half-pixel offset during the projection; either in the matrix or as a shader parameter.
User avatar
bishopnator
Goblin
Posts: 223
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 5

Re: Half pixel offset problem with Direct3D9 renderer

Post by bishopnator »

Maybe offtopic - problem of half-pixel-offset is not only problem of rendering GUI (or rendering 2D elements on screen). In our application (GolfBlaster3D) we render terrain with 2 techniques - parts of terrain near to camera are rendered with full details (using multiple textures) and further parts are rendered only with single texture which was created as top view snapshot of terrain with all parts rendered in full details. We had same problem with this half-pixel-offset when we switched rendering technique on further parts - it was really visible how grass moved due to this offset. And really annoying thing was, that this offset depends on texture resolution (what is logical ofcourse, but bad for programming - it is not constant so it must be uploaded into shaders during rendering per material). We are using only DX renderer so it was not problem to add this offset to our shaders.

My point was that it is not only problem of rendering 2D elements on screen, but it is general problem - if we would use both renderers we would add some 'switch' for computing offsets or use different shaders or something else ... but I think it should be part of ogre (in some way) because in my opinion both renderers (or in future all renderes) should give same result for same input.
juharkonen
Gnoblar
Posts: 13
Joined: Wed Oct 22, 2008 8:32 am

Re: Half pixel offset problem with Direct3D9 renderer

Post by juharkonen »

Thanks for your notes sinbad and bishopnator.

sinbad, could you describe when ogre assigns UV's in object space and when it does not? Have I understood correctly that with 'object space' you refer to the 3D coordinate space that is associated with each SceneNode instance in ogre? Is is correct that eg. meshes attached to a SceneNode define their geometry in object space so they are rendered in a position relative to the SceneNode's position?

Have I concluded correctly that Rectangle2D doesn't use object space as it requires manual correction of pixel offset in compositor? Also the ManualObject quads that my current project uses for screen aligned rendering do exhibit the offset (and I thought they were defined in object space). I have verified that the offset also exists when the texture is displayed with downscaling factor between 1 and 2 instead of 1:1 texel-to-pixel mapping. This is in accordance with bishopnator's note about the offset in his terrain rendering application.

bishopnator, could you describe how you eliminated the offset in your shaders? A sample code would be even better. As a note, the half-pixel offset is specific to D3D9 and is no longer present in D3D10.
User avatar
bishopnator
Goblin
Posts: 223
Joined: Thu Apr 26, 2007 11:43 am
Location: Slovakia / Switzerland
x 5

Re: Half pixel offset problem with Direct3D9 renderer

Post by bishopnator »

ok, little background about my terrain rendering:
I am using 2 base techniques for terrain rendering - multitexture rendering (using special shaders, which creates good looking grass and other terrain materials close to camera) and single texture rendering - parts of terrain which are further from camera. For 2nd technique I create one texture which contains snapshot of whole terrain using multitexture rendering and than I map this texture to terrain with following instructions in shader:

Code: Select all

float2 computeUVOfs(float2 worldPosXZ, float4 vConstTexMapX, float4 vConstTexMapZ)
{
  float x = (worldPosXZ.x - vConstTexMapX.x) * vConstTexMapX.y + vConstTexMapX.z;
  float y = (worldPosXZ.y - vConstTexMapZ.x) * vConstTexMapZ.y + vConstTexMapZ.z;
  return float2(x, y);
} 
where worldPosXZ is world vertex position (only X and Z coordinate (out up vector is Y axis) and vConstTexMapX and vConstTexMapZ are constants which are uploaded to shader.

Code: Select all

Ogre::AxisAlignedBox aabb = ... // our terrain's bounding box
Ogre::TexturePtr pTexture = ... // our terrain's single texture (top view snapshot)
Ogre::Vector4 vConstTexMapX(aabb.getMinimum().x, 1.0f / aabb.getSize().x, 0.5f / pTexture->getWidth(), 0.0f);
Ogre::Vector4 vConstTexMapZ(aabb.getMinimum().z, 1.0f / aabb.getSize().z, 0.5f / pTexture->getHeight(), 0.0f);
That's works very good for me - if rendering switchs from multitexture rendering to single texture rendering there is no moving artefacts (without half pixel offset it is visible that transition between materials are moved).

Whole shader (maybe not important, but it may helps):

Code: Select all

struct VS_INPUT
{
  short2 pos    : POSITION;
  float  height : TEXCOORD0;
};
struct VS_OUTPUT
{
  float4 vPos : POSITION;
  float2 vUVColorMap : TEXCOORD0;
};
float2 computeUVOfs(float2 worldPosXZ, float4 vConstTexMapX, float4 vConstTexMapZ)
{
  float x = (worldPosXZ.x - vConstTexMapX.x) * vConstTexMapX.y + vConstTexMapX.z;
  float y = (worldPosXZ.y - vConstTexMapZ.x) * vConstTexMapZ.y + vConstTexMapZ.z;
  return float2(x, y);
} 
VS_OUTPUT  main_vp(VS_INPUT i, uniform float4x4 viewProjMatrix,
                  uniform float4 vConstTexMapX,               // x-minX; y-1/max; z-offsetX; w-unused
                  uniform float4 vConstTexMapZ,               // x-minZ; y-1/max; z-offsetZ; w-unused
                  uniform float4 vTerrainBox) // xy = offset, zw = square size 
{
	VS_OUTPUT o = (VS_OUTPUT) 0;
	
	// unpack vertex position
	float4 world_pos;
	world_pos.x = vTerrainBox.x + i.pos.x * vTerrainBox.z;
	world_pos.y = i.height;
	world_pos.z = vTerrainBox.y + i.pos.y * vTerrainBox.w;
	world_pos.w = 1.0f;

	// transform the position 
	o.vPos = mul(viewProjMatrix, world_pos);
	
	// compute uv tex coords  
	o.vUVColorMap = computeUVOfs(world_pos.xz, vConstTexMapX, vConstTexMapZ);
	
	return o;
}
float4 main_fp(VS_OUTPUT i,
		uniform sampler2D  colorMap: register(s0) // color map texture sampler
		) : COLOR
{
  return tex2D(colorMap, i.vUVColorMap);
}
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: Half pixel offset problem with Direct3D9 renderer

Post by sinbad »

Ok, I see what you mean in this regard, this is a particular problem when matching subdivided texture seams against larger merged versions, which would suffer from the same issue. What I was referring to was that normally when you're just using UVs as assigned to the objects in a modeller, you don't notice any half-pixel issues because everything is using the same basis.

When you're projecting from the screen, either a UV or geometry offset will have the same effect, but in bishopnator's case UV offsets are the only option since it's not projection, it's matching seams of smaller textures to other larger textures. The general algorithm is to offset the UVs by the offset / the image size (the offset is available as an auto shader binding, see texel_offsets).

I can see why some people might want this to be automatic, but it's actually not that simple. In order to apply it universally, we'd have to offset the geometry at load time, since the approach for offsetting at runtime is different depending on whether you're using shaders or fixed-function. Then you have the problem that you don't know how the UVs have been assigned in the first place - if they've been assigned by a tool that assumes the rendersystem is D3D9-style then it may already have the offset taken into account. Finally, the issue is that most people don't need the offset - it's only in cases like pixel-accurate projection and seam matching that you can actually tell any difference. That's why we don't try to address it in a general sense and leave it to the specific cases to cope with, when they know they're required.
Post Reply