Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Mar 2007
Offline Last Active Yesterday, 02:47 PM

#5005909 Is there anyway to create curved 3D model?

Posted by MJP on 30 November 2012 - 07:26 PM

If we're talking about GPU hardware rasterization, then the only supported primitives are points, lines, and triangles. To approximate curved surfaces with actual geometry you would need to tessellate to triangles. If you don't want to do that, you can shade surfaces as if the surface geo was actually curved. This can be accomplished with normal maps, or even with really simple techniques like interpolating smooth vertex normals across a triangle. It's also possible to discard pixels and manually output depth values, which can give you the outline, shading, and resulting depth buffer of a curved surface. However doing this isn't really practical, since it doesn't play nice with GPU hardware optimizations.

#5005907 DeviceContext->map() using system and GPU memory?

Posted by MJP on 30 November 2012 - 07:22 PM

Strictly speaking, you can't make any assumptions about where resource memory is located or where it might get copied to. The implementation (driver) is free to manage these things however it wants, provided that the end result matches the behavior described by the API.

In practice, drivers for dedicated GPU's are likely to store DYNAMIC resources in CPU-writable memory that's also accessible by the GPU. This memory could be system memory which means that the GPU is required to read it across the PCI-e bus, or it could GPU memory in which case the CPU has to write across the PCI-e bus. Either way there's not likely to be any copying going on, however the driver does have to transparently manage a fixed pool of memory which means it may be making all kinds of book-keeping allocations behind the scenes.

#5005852 DirectX11 2D Book

Posted by MJP on 30 November 2012 - 03:33 PM

Is it made by Microsoft (http://directxtk.codeplex.com/) or is it a project of someone?

It was developed by a Microsoft employee (Shawn Hargreaves, who used to work on the XNA Framework), but I don't think it counts as an "official" Microsoft project or anything like that. Either way it totally works, and it has a very similar feature set to the SpriteBatch in XNA (which many many people successfully used to make their 2D games).

#5005607 CSM help (problem with cascades/shadowmap) [SOLVED]

Posted by MJP on 30 November 2012 - 01:11 AM

So say you have a shadow matrix, such that WorldPosition * ShadowMatrix gives you the position that you want in shadow map space. If you have a view-space position, then you could get the same result by doing ViewPosition * InvViewMatrix * ShadowMatrix. The nice thing about matrices is that you can combine two matrix transformations into a single matrix, which means that if you can pre-multiply InvViewMatrix * ShadowMatrix on the CPU and pass that to the GPU. Then in your shader you just do ViewPosition * ViewShadowMatrix and you'll get the result that you want.

EDIT: I made a rough diagram to illustrate what I'm talking about:


The picture shows a top-down view of the view frustum (the green trapezoid), with two shadow cascades (the red rectangles) whose sizes are marked (which are not to scale). Ignoring the Z dimension for a minute, in terms of X and Y the second cascade is 2x the width and height of the first cascade and is located 1 unit to the right and 0.75 units downwards. Using that, you could project using the first cascade matrix and then apply the appropriate offset and scale to get coordinates in terms of the second cascade. I left out the Z coordinate, but it works the same way.

#5005604 What's the most used 3D modeling software in First-Person Shooter games?

Posted by MJP on 30 November 2012 - 01:01 AM

I've heard of some larger studios using multiple packages, but I wasn't under the impression that it was common. At my current job our tech very tightly integrated with Maya, to the point that the idea of supporting another package would sound like crazy talk. Every once in a while we get an artist that's used to Max, and they just learn to use Maya. Frankly I have a hard time understanding the rationale behind having an engine team that supports more than once package, unless you're licensing your tech.

#5005406 What's the most used 3D modeling software in First-Person Shooter games?

Posted by MJP on 29 November 2012 - 01:11 PM

They definitely aren't using their own tool, but most major studios will have an extensive collection of plugins and scripts that they use in conjunction with their modeling program of choice.

#5005086 DirectX11 2D Book

Posted by MJP on 28 November 2012 - 03:34 PM

If you do 2D via Direct3D, then you have to deal with the 3D API, setting up your pipeline and whatnot, but everything simplifies when you drop the z-axis from your game logic/rendering (even if you still use it to z-order sprites, etc), and you can hide all the details in a wrapper class just once if you like, and never have to look at it again.

Or you can just use SpriteBatch, and call it day.

#5005038 HLSL pixel shader works with magic number (0.3333) but not with (1 / 3) why?

Posted by MJP on 28 November 2012 - 01:18 PM

1 / 3 == 0 (integer division)
1.0f / 3.0f == 0.333333f (floating-point division)

#5004339 "Valve ambient cube"

Posted by MJP on 26 November 2012 - 04:27 PM

For some function defined about a sphere, the ambient cube will store the value of that function in the direction of the 6 major axis directions. So if you're storing irradiance, then you want to store the irradiance about a hemisphere oriented about +X, then -X, then +Y, and so on. This is not "storing too much energy", because when you "look up" an irradiance value from your ambient cube at runtime your value will be the linear combination of 3 values, where the sum of the weights is <= 1. This way if your normal is exactly oriented, you get the exact irradiance value for that direction. Then if the normal is in between the major axis directions, you approximate the value there by blending the "nearby" samples.

#5004119 Adapteva IC has 50+GFLOPS per watt, can graphics benefit from it?

Posted by MJP on 25 November 2012 - 11:57 PM

C'mon guys! With their architecture you get 800MHz * 64 cores which gives you a total of 51.2 GHz!!!! That's wayyyyy more than the puny 16 GHz you get from a GPU!

If that doesn't sell you on their tech, then this mind-blowing performance benchmark is sure to do the trick.

#5003901 HLSL Vertex Shader input types and their alignment

Posted by MJP on 25 November 2012 - 01:02 AM

There's no specific alignment requirements beyond what's implied by the formats you use for your various elements. If you have an element that uses DXGI_FORMAT_R32_FLOAT, then the next element can be 4 bytes after it (since the format implies that the element will be 4 bytes).

The type in your HLSL shader has to match the type specified by the format. If you you use a FLOAT DXGI format, then you have to use the "float" type in your shader. By the same token you need to use "uint" for "UINT" formats, "int" for "SINT" formats, and "float" for "UNORM" and "SNORM" formats.

#5003692 XNA(C#) and Shaders(Effects) - draw an empty screen with shader

Posted by MJP on 24 November 2012 - 12:56 AM

You can just use GraphicsDevice.Clear to efficient clear a render target to a specific color.

#5003691 EVSM performance tip!

Posted by MJP on 24 November 2012 - 12:54 AM

For any value from the depth buffer you can convert to a linear depth value (z component of view-space position) by using a few values from the projection matrix. Just follow the math in the matrix multiplication and you can derive it pretty easily. Doing this still works fine with a projection that uses "flipped" clipping planes. So for EVSM you can just render using "flipped" depth (make sure you switch the direction of the depth test), and then when you perform the EVSM converison/MSAA resolve you can convert to a linear depth value right after sampling the depth texture.

#5003542 Question about instanced rendering performance

Posted by MJP on 23 November 2012 - 12:11 PM

There is almost no difference between an instanced draw and a non-instanced draw on a modern GPU, since vertex fetch is performed by the shader cores.

#5003406 Shader Functions

Posted by MJP on 23 November 2012 - 01:48 AM

Ahh now that's much harder question to answer. Posted Image

It's true that compiling many different "permutations" of a shader can lead to the "explosion" of shaders that you're alluding to. The thing you have to keep in mind is that even if you support 2^16 possible shader variations, your game would never actually use that many. So the trick is to limit your set of shaders to the ones that you actually need. For instance some games have used an on-demand shader system during development that didn't compile and load a particular permutation until a mesh was loaded that needed it. They would then save those shaders to a cache, and once the game was QA'ed they would ship the game with the pre-compiled cache stored on disc. Some games will simply pre-determine the shaders needed as part of a level build step, and pre-compile them. In practice it depends a lot on the game, and how the game's shader/material system is setup.

Putting variables in constant buffers is a different problem. With that approach you don't have to deal with compiling or loading a lot shaders, and you can stick lots of variables in the constant buffer without worrying about doubling the number of shaders. Instead you have to deal with the runtime performance of having a branch (which is pretty cheap on modern hardware, especially since all threads will take the same branch) and suboptimal code from the compiler not being able to optimize things out. However it's possible to mix this approach with shader permutations, in order to minimize the downsides of either. In general I would suggest putting expensive, complex functionality in a permutation rather than a branch. This will ensure that you don't suffer a higher register count for materials that don't use the expensive feature.