PhillipHamlyn

The only thing that namespaces do is to segment classes of the same name from each other. The author may structure their namespaces in some logically useful manner, but it doesn't mean anything to the compiler - they just serve to uniquely identify a class.

Ok, I need to qualify my earlier reply; In XNA4 Vector4 textures can only use Point Sampling in Vertex Shaders. I have no information on whether this is different for SlimDX or other frameworks, so you might be able to rely on the sampler to do the Wrap for you.

 

So I vary the height of the vertex like this;

// Now sample the noise texture to add some variation into the nearby tiles.
float4 noiseCoordinates = (float4)0;
noiseCoordinates.x = heightMapUV.x * (Param_HeightMapWorldSize ) * 10;
noiseCoordinates.y = heightMapUV.y * (Param_HeightMapWorldSize ) * 10; 
noiseCoordinates.z = 0.0f;
noiseCoordinates.w = 0.0f; // First mip map
		
float4 noiseHeight = tex2Dlod(VertexNoiseTextureSampler, noiseCoordinates);
worldPosition.y += (noiseHeight - 0.5f) * 2;

I do this by generating a simplex based texture as part of my compilation cycyle and use the texture in the game engine just like any other texture. In the shader I sample the noise texture using Wrap and just use the camera world position XZ, suitably scaled up or down depending on the density of the nosie required, as the texture UV parameter. Because Vertex Texture Fetch only supports Point sampling, you need to roll your own Wrap method. (at least this is true for XNA4 and Vector4 textures - other implementations might not have that restriction).

Hi,

 

Just to keep the trail clean, and to answer my own question.

 

Since Point sampling is the only one allowed for a vertex texture fetch (VTF) and it works on nearest point (i.e. round()) not trunc() most examples of manual linear interpolation will not work if the Vertex position moves between frames (such as when you are doing a geoclipmap or other camera-anchored vertexes which then use world oriented data for height lookups or other stuff).

 

Most examples dont really care if the Lerp operation is offset agains the "wrong" pixel in the texture. When you are presenting a camera-anchored vertex buffer then the user will see all sorts of popping and flipping if you dont change the manual linear filter implementation.

 

I haven't tested this thoroughly, but I need to check the actual pixel that is sampled by calculating my texture offset using a trunc() of my initial texture UV * textureSize. I can then safely Lerp() the Frac() of the initial texture UV * textureSize since I know that I have definitely sampled the correct pixel, and not been rounded to the next one (in which case frac() would be useless).

 

I'll post my outcome once I've tested this.

// Input Image is a byte[] from your Png
System.IO.MemoryStream memoryStream = new System.IO.MemoryStream(this.InputImage);
memoryStream.Seek(0, System.IO.SeekOrigin.Begin);
Texture2D intermediateTexture = Texture2D.FromStream(deviceAccessor.GetCurrentGraphicsDevice(), memoryStream);

Texture2D texture = null;
RenderTarget2D renderTarget = new RenderTarget2D(deviceAccessor.GetCurrentGraphicsDevice(), InputImageSize.Width, InputImageSize.Height, mipMap: true, preferredFormat: surfaceFormat, preferredDepthFormat: DepthFormat.None);

BlendState blendState = BlendState.Opaque;

currentGraphicsDevice.SetRenderTarget(renderTarget);
using (SpriteBatch sprite = new SpriteBatch(currentGraphicsDevice))
{
    sprite.Begin(SpriteSortMode.Immediate, blendState, samplerState, DepthStencilState.None, RasterizerState.CullNone,
            effect: null);
    sprite.Draw(this.IntermediateTexture, new Vector2(0, 0), Color.White);
    sprite.End();
}

texture = (Texture2D)renderTarget;
currentGraphicsDevice.SetRenderTarget(null);
intermediateTexture.Dispose();
return texture;

Partly to answer some of my question; I decompiled GraphicsDevice and it does cache the last Set RasterizerState and BlendState and checks to see if you are changing from the cached one. However both RasterizerState and BlendState are classes and therefore the GraphicsDevice only checks that the reference pointer is the same as the last used - and I can't see that the RasterizerState and BlendState classes override the Equals method to compare the content of the states with each other.

 

So - I've got some clarity - XNA will cache the last used reference to a graphics resource, but since you cannot change the content of a graphics resource once committed to the graphics device (i.e. change the graphicsDevice.RasterizerState.CullMode directly) you have to create a new instance of the RasterizerState (or other graphics resouce) meaning that XNA will not pick up that Reference A is equivalent to newly created Reference B, meaning its cache is only marginally beneficial.

 

Do programmers tend to define and manage their own Graphics State caches to aid in defensive programming ?

 

Phillip

Depends on whether you are mostly reading from the DB (in which case, put indexes that cover every Where clause) or the DB has quite a lot of writes (in which case you need to be a little more discerning).

 

However; on balance, the DB is there to be read - you will read it much more often that write to it, so generate indexes that cover all your Where clauses, and only remove them if you find they are not used.

 

Also, generally dont bother indexing a table that will have < 100 rows; most optimisers wont use the index.

Depends on the framework implementation of String.Join. I expect its StringBuilder internally.

... and using my trusty copy of .Net Reflector I see that it does indeed use StringBuilder internally.

If its C# or any other .net language you absolutely must use StringBuilder.
Consider - all strings in .net languages are immutable - they cannot be changed once created. So;

A = A + B then
A = A + C then
A = A + D
essentially means creating a new string called A and filling it with A + C. Repeat 10,000 times and you have the memory heap fragmentation from hell.

StringBuilder keeps a list of the pointers to the original strings, calculates the size, and copies them all in one operation, meaning the intermediate instances of A shown above are not created. Hugely faster and more memory efficient.

...

You introduce an indirection which adds an extra method call in means of performance.
Furthermore not using Polymorphism where it is appropriate will increase code size dramatically.

For testing this should imo not be a runtime decision, but a decision at build time.
In C++ you can easily swap in mockup classes in a type hierarchy with #ifdefs or by including different directories for unit/integration tests.
Not sure about C# though.

But inheritence uses a virtual method lookup anyway, so no net loss ?
Dont agree with the code size argument - I dont see a difference in code size either way. Same logic; same compiler.
Agreed you can use Mocking, but inheritence concepts indicate that the inheritor "is interested in" or "knows" about the implementation details of the inherited class and extends that implementation, Mocking replaces the implementation with a different one and therefore invalidates the assumptions on which the inheritence contract was originally made. With a dependency inversion approach, no assumptions are made about the implementation because these are interfaced away leaving only the calling contract.

In most cases, IMHO, virtual methods are better replaced with a plug-in system providing dependency inversion rather than concretet dependency, since its more amenable to automated unit testing and mocking. Dependency inversion allows the assembly of the class functions at runtime without implying any specific hierarchy.

As an example; a pseudo logging class using inheritence -

Class SystemLog : FileWriter
{
public WriteLog(string comment)  : base(comment);
}

Using dependency injection

Class SystemLog
{
public IWriteDestination WriterStream {get;set;}
public WriteLog(string comment)
{
    this.WriterStream.Write(comment);
}

}

The first example requires a class called FileWriter whose functionality is expressly built into the class hierarchy, but the second does not need this dependency; its entirely ignorant of how the functionality on which it depends is provided. The first example has the class "knowing" at design time about which class it will use to implement its features, but the second example has the class being ignorant of what other class will provide this function (allowing for a test framework to provide a replacement implementation without affecting the calling class).

Although polymorphism is a solid OO concept, anything but the simplist inheritence hierarchy requires a lot of design level decisions which could reasonably be left until runtime.

So - in short; Virtual generally is better replaced by a

public MyProvider : IProviderClass
{
    get;set;
}

Phillip

Dagz

This is symptomatic of using Event Handlers but not unhooking them. Its a common mistake to make if you are new to .net. Look for any event handlers you hook up and make sure you are unhooking them deliberately at some stage. What tends to happen is they get hooked at some stage but never unhooked. This means that the class that has the event declaration has references to all those classes that hook that event, and if that event raising class is a static or long lived class, the classes that are hooking its events never get released to be GC'd - and even worse continue to have events raised on them long after their utility has gone.

This might not be precisely your problem but its a common anti-pattern that leads to memory loss and laggy behaviour in .net systems of all kinds.

I use something like this (psuedocode)
[source lang="csharp"] System.IO.MemoryStream memoryStream = new System.IO.MemoryStream();System.Drawing.Image bitmapImage = System.Drawing.Image.FromFile(myFileName);bitmapImage.Save(memoryStream);memoryStream.Seek(0, System.IO.SeekOrigin.Begin);Texture2D texture = Texture2D.FromStream(deviceAccessor.GetCurrentGraphicsDevice(), memoryStream);[/source]

I dont think that is possible. The heightmap texture will be sampled in the Vertex Shader based on the geometry and interpolated for the triangle inners. To have a hole you'd have to have a hole in your geometry, such that the Vertex Shader would not get passed the triangles that describe the hole. I've never thought about that possibility - so I could be way out of line, but I've got a height map based terrain and I also would struggle to punch a hole in the geometry without doing it explicitly.

Alternatively you could just paint the Zero height region transparent - after all it only needs to look like a hole doesn't it ?

Vertex and Index buffers are handles to resources that youve have sent or intend to send to the GPU. The VB/IB structures are not expensive resources in themselves but if neccessary you can create and dispose them as you need. Generally you have one or many VB/IBs per model, rather than attempting to reuse them.

In that sense they are similar to programming in IO streams (in fact if they were called VertexStream and IndexStream you might get a better analogy - although its not perfect). Like IO stream programming, once youve committed data into a stream you rarely modify the contents, as you have explicitly "shared" the contents between other holders of the stream pointer - in this case the GPU. You can modified the contents of the VB/IB but its only done in specific circumstances for specific effects.

If you attempt to channel all your data per frame through one VB/IB you are preventing the GPU from seeing the "whole picture" and force it to process your draw call serially rather than use the parallelism that they specialise in.