# Tsus

Member

337

1186 Excellent

• Rank
Member
1. ## How to calculate Lumens?

@Hodgman: I have this vague feeling that it's not my place to correct you, but since you asked...     You're mixing photometric and radiometric terminology, here. Candela (cd) is the unit of luminous intensity (photometric). The equivalent radiometric quantity is radiant intensity and it's unit is watts per steradian.     Candela is lumen per solid angle.     The unit of luminance (photometric) is: cd/m²     @CGEngine: If I'm not totally mistaken, you can just plug the photometric units into the rendering equation. For some reason the (English) rendering literature often uses the radiometric names for the quantities (radiance, irradiance, ...), but is using photometric units (lumen, candela, ...), which is totally confusing.   The radiometric units are used in radiation physics. The photometric units are used whenever the human perception is concerned. (They just differ in the way how they weight light of different wavelengths. If you're not working with spectral lighting effects, you don't really need to care.)   The dot product formula you posted earlier is the photometric way of mixing RGB values into some luminance value (the weighting is according to the spectral response curves of the "average" eye).
2. ## Recommend a book for algorithmic 3D modelling theory

Hi axefrog,   I have some book references for you that cover at least the NURBS part.   "Fundamentals of Computer Aided Geometric Design" by Hoschek and Lasser is a standard reference for modeling with curves and surfaces. It also covers various methods for interpolation, intersections, blending and smoothing of surfaces.   In Farin's "Curves and Surfaces for Computer-Aided-Geometric-Design", there's a bit more background on continuity, splines, and different kinds of operations you can do with curves and surfaces. It also contains exercises.   Here are some applets that demonstrate a few of the algorithms discussed in those books.   Hope that helps a little. ;) Cheers!
3. ## Depth stencil state issue

Hi!   The black depth channel is somewhat expected, due to the non-linear distribution of the z-values. Right beside the combobox where you selected the "depth" channel, you have a gray bar that allows you to filter the range displayed linearly. There are tiny triangles (top-left at the bar, and bottom-right). These are the lower and upper bounds. You can move them around, so that you have the lower bound around 0.95. That should show you something.   On the top left of the window is a small "save" icon. You could save the PIXrun and upload it, so that we might have a look. Best, Tsus
4. ## Depth stencil state issue

Ok. So, with all resources being successfully created and no errors in the output window during draw calls, it's time to use a graphics debugger like PIX. PIX is contained in the DxSDK and allows you to capture the draw calls and states for a frame (every time you hit F12). When clicking on a draw call in the list presented to you in PIX, the vertices of the triangles are shown before and after transformation. If you do a right click on the rendering output you can debug individual pixels and see, why fragments were discarded. Also, you can dig into the states bound at a draw call. Hopefully, this sheds some light on the matter.
5. ## Depth stencil state issue

Hi eltharynd, Usually, CPU access flags are not required for the depth buffer. Try to turn on the debug layer, as eppo suggested. D3D will most probably tell you what is wrong. The behavior you described sounds like invalid parameters. Pass the flag D3D11_CREATE_DEVICE_DEBUG into the Flags parameter of the D3D11CreateDevice call. Could you check that all your mDevice->Create... methods return S_OK? If not, the debug layer will tell you in the Output window of visual studio, why the Create-method failed. (If you run in Debug mode with F5, not Ctrl+F5.) Clearing structs with ZeroMemory is a good practice (in my eyes). Could you do it for the depth stencil desc, too? (Just to be safe.) ZeroMemory (&dsDesc, sizeof(D3D11_DEPTH_STENCIL_DESC)); Also, you have some copy paste error when clearing the depth stencil view desc. It should go: ZeroMemory (&depthStencilViewDesc, sizeof(D3D11_DEPTH_STENCIL_VIEW_DESC)); Just to be safe, set a rasterizer state. Whenever you move code around, you don't want to depend on states of some previous code block. D3D11_RASTERIZER_DESC rsDesc; ZeroMemory(&rsDesc, sizeof(D3D11_RASTERIZER_DESC)); rsDesc.CullMode = D3D11_CULL_BACK; rsDesc.DepthBias = 0; rsDesc.DepthBiasClamp = 0; rsDesc.FillMode = D3D11_FILL_SOLID; rsDesc.AntialiasedLineEnable = false; rsDesc.DepthClipEnable = true; rsDesc.FrontCounterClockwise = true; rsDesc.MultisampleEnable = true; rsDesc.ScissorEnable = false; rsDesc.SlopeScaledDepthBias = 0; if (FAILED(mDevice->CreateRasterizerState(&rsDesc, &mRsBackfaceCulling))) return false; Then, later: mDeviceContext->RSSetState(mRsBackfaceCulling); And don't worry. You'll figure it out. Best, Tsus
6. ## Depth stencil state issue

Hi eltharynd! If you don't need the stencil test, you probably want to disable it. dsDesc.StencilEnabled = false; In this case, you can put full precision into the depth value by using a full float for it: depthTexDesc.Format = DXGI_FORMAT_D32_FLOAT;   Currently, your depth testing function permits all fragments to be written. Instead, let only fragments through that have a smaller depth value. dsDesc.DepthFunc = D3D11_COMPARISON_LESS_EQUAL;   It might be just due to copy-pasting into the browser, but did you use the correct depth stencil view description, when creating the depth stencil view? (2nd argument changed) mDevice->CreateDepthStencilView(depthStencilTexture, &depthStencilViewDesc, &mDepthStencilView); I guess you did, but for completeness I'm just saying it: You bound your depth buffer like so, right? ID3D11RenderTargetView* rtvs[] = { mRenderTargetView_Backbuffer }; ImmediateContext->OMSetRenderTargets(1, rtvs, mDepthStencilView); Do you clear the depth stencil view before drawing? mImmediateContext->ClearDepthStencilView(mDepthStencilView, D3D11_CLEAR_DEPTH, 1, 0); Also, were all your resources successfully created? (That is, they are not NULL?) Best, Tsus
7. ## blending question

Hi! Will your float texture ever contain negative values? It's not strikingly elegant, but: in case you need to clear a pixel, you could write out a large negative value, giving you after the additive blending something that is smaller than zero. When you use the texture later, you could clamp the value again up to zero: max(0, texture_color).

9. ## DX11 D3D11 - RenderTargetView at slot 0 is not compatable with the DepthStencilView

Hi! Your render target view (that views the texture to render into) and your depth stencil view (the corresponding depth buffer) have different multi-sampling settings. When using multi-sampling, every pixel needs to store extra data for the sub-samples (their depth and the coverage bits). Each texture resource is prepared for one certain multi-sampling setting and to make them work together, both the color texture and the depth buffer (after all, it’s just another texture) need the same setting. You can have resources with different settings, but you can only bind them together, if their settings coincide. If you disable multi-sampling, it would be: sampleDesc.Count = 1; sampleDesc.Quality = 0; High-quality 4x MSAA (for instance) is achieved by setting: sampleDesc.Count = 4; sampleDesc.Quality = 16. Keep in mind that MSAA comes at a cost. If you don’t need it, try to avoid it. Also, combining multi-sampled with single-sampled textures requires you to convert one into the other. (I'd advise you to first familarize yourself with the rendering to textures, before working with multi-sampling)   Okay, so try to set in your default texture (system class): texd.SampleDesc.Count = 1; and make sure that your view dimensions are set to the single-sampled types, e.g., for the depth stencil view: D3D11_DSV_DIMENSION_TEXTURE2D  (not: D3D11_DSV_DIMENSION_TEXTURE2DMS).   Cheers!
10. ## Waterfall textures

I'm not quite sure, but.. right next to the big rock in the center seems to be a pattern that repeats (the faster texture layer). Somehow the layer seems to move very, very slowly perpendicular to the flow direction, because this patterns moves after 3 or 4 iterations closer to the rock. From that I'd guess they used static textures. Perhaps just try to implement this with static textures first. I guess, having nice textures does the trick, here.