Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Oct 2011
Offline Last Active Feb 14 2013 01:17 AM

#4876148 Full Screen/Post Processing PS On SDK CubeMap Example

Posted by on 23 October 2011 - 05:07 PM

I may be walking into a bee hive here, but I am going to try to help - and give some suggestions even if you don't want them. The basic topics that you have questions about are the very first principles of working in computer graphics and their APIs. In order to get something done, you must have some basic background knowledge of the subject or else it isn't going to do you any good to get through this tutorial task.

I have rendered my own scenes in opengl, texture loading, terrain generation with perlin noise, and custom shaders. I fully understand the high level concepts, and I understand pixel shaders rather well. I don't work as an engine programmer, I'm actually a tools programmer, and recently I created an HSV color picker for WPF with the bulk of the work being done on the GPU by an HLSL shader. My area of concern as a programmer is human-computer interaction and ease of use, not rote memorization of particular implementations. If it's any consolation, I have read through every documentation page in the D3D SDK sample browser that deals with the basics. As I have said, they are not tutorials, I cannot think of an analogy better than the airplane analogy I gave above.

For example, do you have any concept of the rendering pipeline? There is geometry fed into the pipeline from vertex and index buffers when a draw call is executed, and that geometric data is transformed in a vertex shader to position it within the current view port. That transformation is done with world, view, and projection matrices, which are usually concatenated together and supplied to the vertex shader through a constant buffer. That transformed geometry is then rasterized to produce pixels, which are then subsequently processed with the pixel shader (similar to what you have already provided). This overview covers the minimal pipeline setup, with all other programmable stages disabled (which is done by setting null into the corresponding shader slots).

What you are trying to do is cover the entire viewport with a single triangle or two, so that with a minimal amount of geometry you are going to invoke a pixel shader for every pixel of your render target. The choice is yours in how to accomplish this - you create vertex buffers with some input geometry, and at the output of the vertex shader you need to have the x and y coordinates over the range of -1 to 1 being covered by the geometry. If you use one triangle, then you can just make the input vertex positions be large (such as v0= {-1,-1,0,1} v1={-1,20,0,1} v2={20,20,0,1}. With these vertex positions, your geometry doesn't need to be modified at all - you can simply pass the input values to the output of the vertex shader. This will then produce a single fragment for each of your pixels, which is what you wanted in the end.

The actual code snippets to create a vertex buffer, bind it to the pipeline, setup the corresponding pipeline states, and then call the draw call are all available on the internet. In fact, most of them are available in the DXSDK documentation... However, I would suggest that you not simply hunt for the code snippet that you need for this one task, and rather that you invest some time into understanding more of what you are doing with the pipeline.

Yes, that's all nice. And I promise that if I understood how to do this I wouldn't have made this thread.

I think you instructors in college may have done you a dis-service by spoon feeding you code tasks - if you don't know anything at all about the underlying system that you are programming, then have you actually learned anything by following a recipe style list of things to do?

What evidence do you have to back up this statement? Are you a teacher? What statistical information do you have correlating a particular technique with retention and self-reliance?

I don't think so - but that is just my opinion. So when you write your code sample for your portfolio, if someone checks it out and they ask you to modify it to do something else, what will you tell them??? I know it is a gigantic topic to dive into, but if you put the time into it, you will surely learn about it and be better off not to need to rely on others to provide sample code for tasks like this. Again, this is just my opinion, but I truly hope that you follow my advice and spend some time learning the background info on at least some of this stuff - you just might like working with it!

Oh I would love to. Here is the use case scenario that I encountered. Right, I search for tutorials on the internet on learning Direct3D, and every last one is exactly the same: mile-high overview of the topic with mathematical graphs and representations of vector spaces, along with working code. It is missing the most important ingredient, the very essence of learning, and that is interaction and feedback. I understand what you are saying, and you think I would be better off learning from the ground up, but what I am trying to tell you is, and this is not just true for Direct3D, the information out there is not good enough. I know for a fact that if I knew everything there was to know about Direct3D, I could write a tutorial that nobody would ever be confused about.

I work hard every day and even on weekends implementing the functionality my clients want for my company. WPF is a very counter-intuitive framework for computer science students because it goes against everything you learn from assembly up. All computer instructions translate into load, store, math, conditional, and jump statements in the end. Everything from delegates and polymorphism to threading and serialization and abstract data types are all just combinations of these five elements. But WPF throws a lot of the traditional programming styles out the window and uses instead static property tables and automatic synchronization of variables and whatnot. It was extremely difficult to learn and the tutorials out there are just as bad as Direct3D.

I am not saying that what you ask me to do is impossible, I am saying there is a better way. I promise you that if you researched it yourself and experimented with people who have never used graphics libraries before, you would quickly change your mind about spoon feeding tasks.