• Content count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About nietakt

  • Rank
  1. Any chances of getting an answer or a hint?
  2. I am having problems when trying to PIX-run apps that use D3D11 API but at D3D 9.* feature levels. The very same app built using feature levels >= 10.0 does not generate such problems. It's hard for me to list all the things that are unavailable, but the issues I've come across so far are: (i) the inability to view geometry (Mesh tab) and (ii) depth buffer. All the information I get from PIX is the following vague message "There was a problem". I am attaching screenshots illustrating the issue for a very simple app (a single non-textured quad) - one is for 10.0 and the other for 9.1 FL. Is this a known issue? Do you happen to know how to make PIX fully functional for D3D11 at 9.* feature levels? Thanks [img][/img].
  3. Oh, so it seems I cannot grasp the logic behind your approach . If you do use the technique described in gamasutra, you should have several shaders (for separating glow sources, blurring and combining). I think we will sort it out, but I need you to post all the shaders and also describe what you do on the CPU before and after launching them, since I cannot really get much from just a single PS.
  4. I cannot really understand what you are trying to say here, but the glow as I know it is approached a bit differently: [list=1][*]you first draw the glow sources to an intermediate texture (let's call it glowTex);[*]you blur glowTex texture;[*]you add the original image to the blurred glow sources texture;[/list] As far as (1) is concerned - I guess you want to do a simple multiplication of the non-glow pixel color and the pixel value from your mask-texture to pick only those pixels which are supposed to glow. I suggest you read this [url=""]article[/url] from gamasutra. I am bit anxious that I may be writing obvious things while you're trying to achieve something I cannot comprehend - if so, I apologize .
  5. Okay, did it :]. The first rating was not from me, seems somebody else has found your reply helpful as well. See you some other time, nietakt
  6. Yep, that's it! unbird - thanks a lot^2 . (I tried to rate you, but couldn't find the proper switch).
  7. Hello! Just a short preamble before I actually begin - precision and repeatability of computations is *very* important to me, that is why I even noticed the issue to be described in a sec. Well, calling the Device constructor does *something* to the calling thread. I cannot say what it is (hence the question), but it changes the way this thread multiplies doubles. Resultantly, the thread seems to cast them to floats and back to doubles. Here comes the example: [code] //init. //... //double multiplication test double a = 0.86602539649920685; double b = 1.0000000000000000; double c = a * b; // c = 0.86602539649920685 //device creation _device = new Device(d3d, iAdapter, devType, this.Handle, flags, _presentParams); //double multiplication test double d = 0.86602539649920685; double e = 1.0000000000000000; double f = d * e; // f = 0.86602538824081421 [!!!] double g = (double)((float)d * (float)e); // g = 0.86602538824081421 [!!!] [/code] And as of now, the thread will do the same lousy thing whenever it stumbles upon double multiplication. However [list][*]calling the very same multiplication in a separate thread (once the main thread has gone through device creation) -> okay[*]forcing the device creation to a separate thread (just for testing) -> the main thread remains okay[/list]and that is why I guess it must be a certain thread 'setting' or whatever. The question: what is the reason for this and can I sanely undo what device creation seems to be doing? Thanks
  8. Okay, now I get it :). Thank you for the sound explanation, jpetrie. See you next time!
  9. No ideas? Or maybe my mumble was unclear?
  10. First HLSL Attempt

    I don't really get the whole picture, but I've noticed a strange detail. tweenEffect->SetMatrix("proj",&matr);//Used to be SetVertexShaderConstantF() tweenEffect->SetMatrix("view",&matr);//Used to be SetVertexShaderConstantF() I may be missing something, but you seem to pass the same matrix (whatever it holds) as both view and projection and then multiply them in your VS. Is that what you need?
  11. Hi there! As the subject says, I'm having a problem with DepthStencilSurface in SlimDX & D3D9. The thing is that according to my general experience/observation and [url=""]this[/url] article all the DX objects NOT created by the application explicitly don't need to be released (= no need to call Dispose() on them). And this works e.g. for the backbuffer: [code] Surface bbuf = dev.GetBackBuffer(0, 0); //doing something super-duper with bbuf... //then doing many other things (device is still using the same BackBuffer) //quitting the application //=> no leak (Total of 0 objects still alive.) [/code] However, when I get the DepthStencil surface, it keeps leaking: [code] Surface ds = dev.DepthStencilSurface; //doing something unimaginable with ds... //then doing some cool stuff again (device is still using the same DepthStencil) //quitting the app //=> Object of type SlimDX.Direct3D9.Surface was not disposed. [/code] Then again, if I do call Dispose(), like this: [code] Surface ds = dev.DepthStencilSurface; //doing something mind-blowing with ds... ds.Dispose(); //then doing some cool stuff once again (device is still using the same DepthStencil) //quitting the app //=> no leak [/code] I find it pretty counterintuitive - is there any reason for this? Thanks :). P.S. SlimDX guys - this question is in no way trying to belittle your efforts, SlimDX is very useful and handy - thank you for your work :). [Edited by - nietakt on October 23, 2010 4:29:56 AM]
  12. Yet another DOF question

    Emm, okay, I was wrong. This thread can be killed. Just in the very improbable case some of you had the same problem: in the linked article, when you look at the page number 10, you will see that the blurriness measure (f) is forced into the interval [0, 1] (with 0 and 1 both representing max-blurriness and 0.5 no-blurriness), which makes the aforementioned line simply making discRadius value be in the range [0.5, 5] proportionally to the blurriness measure, with a "minimum" at 0.5. It also makes me feel like a moron. Sorry you had to go through that and see you in different threads, nietakt ;] [Edited by - nietakt on January 16, 2009 8:21:52 AM]
  13. Hello I am trying to create a DOF shader roughly based on the article/presentation: Summarizing it, DOF is obtained by: [1] Pre-storing depth-and-focal-pont-based blurriness measure (per pixel) [2] Blurring the pixels basing on the pre-stored blurriness measure If you think I should write something more - please tell me, I will expand this hyper-short summary. What I want to ask you about, is a piece of code in the page number 18 of this paper, function PoissonDOFFilter, the line where discRadius ic calculated. discRadius = abs(cOut.a * vMaxCoC.y - vMaxCoC.x); where discRadius is the radius of the Poisson disc filter kernel, vMaxCOC.y and vMaxCOC.x are the diameter and radius of the maximal circle of confusion, respectively (paper hard-sets them to 10 and 5 pixels); cOut.a holds the pre-stored blurriness measure (range [-1, 1]). The question is - why (the heck) is the discRadius calculated in such a strange fashion? As far as my understanding of this thing goes, discRadius should be simply proportional to the absolute value of the blurriness measure, however, if you draw the function y(x) = abs(10 * x - 5), you will see that this is not the case. The values (y) for negative arguments (x) will grow faster than the positive ones (head-start of 5), and for the x-interval [0, 0.5] y (discRadius) actually decreases with the growth of x (blurriness measure)! Well, either I am totally mistaken here or, hm, or I don't know what. If you can make anything out of it - please help. Thanks! PS I guess I can only expect help from someone, who has actually gone through this article or knows the case from their own experience, since my summary cannot be really helpful with my question.