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 11 Sep 2009
Offline Last Active Yesterday, 11:59 AM

#5088370 Is SSAO view dependent?

Posted by Waaayoff on 23 August 2013 - 07:27 AM

Ok so i took another look at the code that uses position directly instead of reconstruction and found a bug. Fixed it and got the following result:




Which looks correct, right? If so, it's the damn reconstruction code again. It just won't work!!

#5078741 Per-Pixel Point Light

Posted by Waaayoff on 18 July 2013 - 11:52 AM

Output the normals from the pixel shader as colour. Do they look correct?

#5075694 Precomputed Atmospheric Scattering - Irradiance table?

Posted by Waaayoff on 06 July 2013 - 05:43 AM

I'm trying to implement Bruneton's algorithm but i'm not sure the irradiance results are correct. The output texture is black but the values aren't zero. If i multiply them by 100 i get the following:





Which closely resembles the image found in this implementation by Stefan Sperlhofer. So my queston is, is the table supposed to have such low values? Because the Transmittance and Inscatter tables don't.


Also, in the algorithm the single irradiance is multiplied by zero and discarded... Why calculate it in the first place???

#5074106 a = b = new c?

Posted by Waaayoff on 30 June 2013 - 04:09 AM


Also, I didn't realize it was that unclear to read...

Then why did you create this thread? ;-)

You weren't sure how it works, that's IMHO a good proof that it isn't clear to read (at least for you and as it's your code...).



Yes but that's like saying i shouldn't use smart pointers because they're not readable for me since i don't know how they work.. I get what you guys are saying about readability but i just thought this was a simple assignment operation that was common knowledge for non beginners (unlike me)

#5073525 Terrain lighting seams?

Posted by Waaayoff on 28 June 2013 - 02:19 AM


I was thinking maybe it's because my normals are being interpolated when sampling the chunk normal map in the pixel shader?
Sounds reasonable. If you're using REPEAT texture access you're set up for surprises. Real thing is, you don't assemble chunks to make a big terrain. We slice big terrains into chunks instead. All bounduary samples must use inter-chunk fetch. Seamless chunks hide the problem at an extreme authoring cost and limitation, don't do that.



I already use neighbour chunk vertices for border cases if that's what you mean



Is this seam there if you just go by normals, no normal maps?


What do your texture coordinates look like?


(Your normal map isn't in a texture atlas, is it?)


Yes, i just tested and the normals look fine when passed with the vertex. I guess it is a problem with the texture sampling... Any idea how to fix it? Or rather, why not just pass the normals instead of using normal maps? Does bump mapping even work when the texture resolution is the same as the vertex resolution?


And no i'm not using an atlas; a separate texture per chunk



If you are using bezier patches, make sure you are joining your patches with at least C1 continuity.


I don't even know what that means tongue.png

#4991567 Effect/Shader system design :: variable/cbuffer system

Posted by Waaayoff on 18 October 2012 - 03:52 PM


After much thought i approached the problem like this: (Note that this is largely based on the Hieroglyph 3 engine)

I have a ShaderParameter abstract class that every variable type (vector, matrix, texture, etc..) inherits from. The derived classes (one for each type) contain the data. You can call it to get/set data, get type.. This class also has an Update ID (more on this in a second).

Next i have a class that the user interacts with to set shader parameters. The variables are created when a new shader is compiled and stored in an std::map (or hashmap if you want).

Now I divide my parameters into 3 'types' just like the D3D API: Constant buffers, textures and sampler states. A shader class has 3 vectors that contain wrappers around the D3D parameters. The Constant Buffer wrapper has a pointer to the actual buffer and a list of variable descriptions that belong in that buffer. The description struct looks like this:

struct VariableDesc
ShaderParameter* pParameter; // pointer to variable
unsigned int UpdateID;
unsigned int Offset; // offset into the buffer

Now the UpdateID variable is used to check if the buffer needs to be updated. Whenever the user sets a new value for the variable, its UpdateID that i talked about before is incremented. When you're binding a constant buffer, you loop through its variables and if one of the VariableDesc's UpdateID doesn't match the ShaderParameter's UpdateID, you remap the buffer's content. This is a simple optimization.

Next up you will have a RenderEffect. This is a simple POD struct that contains shaders and render states. It is passed to the Pipeline class which is responsible for binding everything. The RenderEffect doesn't really need to know about the details and so it has no functions.

Finally you have a ShaderStage. This one is an intermediary between the Shader class and the Pipeline class. It simply exists to take care of redundant API calls. Since the Shader class has a list of wrappers in contiguous memory and not the actual D3D pointers, the ShaderStage collects the D3D data and binds all shader resources in 4 calls. One for the shader, one for the cbuffers, one for the textures and one for the samplers.

I can't post code now but if you want i will when i get home. (Be warned though, there's a LOT of it since we're talking about the core of a rendering engine)

#4983348 Draw a Textured Quad

Posted by Waaayoff on 24 September 2012 - 02:35 PM

I see that you are not doing any error checking. I realize you're a beginner but it can help a lot. Most DirectX functions return an error value if they fail. You should check for that :)

I believe you forgot the texture file extension in this line:
D3DXCreateTextureFromFile(d3ddev, L"ParticleSmokeCloud64x64", &d3dtex);

#4980094 D3D11: CORRUPTION: ID3D11DeviceContext::ClearRenderTargetView: First paramete...

Posted by Waaayoff on 14 September 2012 - 09:52 AM

Insert a breakpoint at the ClearRenderTargetView function line and run it. Does g_pRenderTargetView point to NULL?

If so, the render target wasn't created properly. Also make sure you're setting the render target beforehand.

#4974190 Terrain normals messed up, don't know why?

Posted by Waaayoff on 28 August 2012 - 11:53 AM

Oh. My. God. Kill. Me. Now.

You were right. I forgot about some debugging code i left in my renderer where i bind the shader parameters only once. Changed that and everything worked. I feel so stupid right now.

Anyway, thank you!!!!!!!!

#4953944 Chunked LOD vertex data?

Posted by Waaayoff on 29 June 2012 - 06:56 AM

I don't know if it's relevant but i'm implementing the Rendering Very Large, Very Detailed Terrains version.

#4952380 assimp nodes?

Posted by Waaayoff on 24 June 2012 - 11:42 AM

... I just have three more questions. in your GLSL vertex shader I assume your "joints = bones"? ...

Yes. These terms are used interchangeably in animation.

#4950887 assimp nodes?

Posted by Waaayoff on 20 June 2012 - 02:58 AM

Bone indices indicate which bones affect a certain vertex the most. For example, assume you're processing a vertex on your player's elbow. That vertex will probably only have 2 bone indices (and hence 2 weights, since #indices = #weights). One bone index will be for the upper arm bone, and one for the lower arm bone. Now these indices are used to retrieve bone matrices from the entire skeleton, which is defined as FinalTransforms in my shader, and as bonesMatrix in larspensjo's.

Simply put, bone indices are just numbers that let you know where a certain bone's transformation is in the matrix array. That way you can retrieve the required matrix and multiply it by the weight.

As for my shader, you can ignore the loop. It just ensures that the total weight is unity if the vertex is affected by less than 4 bones. I have no idea why i didn't do that in the preprocessing. Just make sure the total bone weight for a vertex is equal to one when you're importing the data from assimp, and use larspensjo's shader :)

#4950425 Making a succes game from a to z

Posted by Waaayoff on 18 June 2012 - 05:50 PM

First things first, it doesn't sound like you have any programming experience whatsoever. So that's where you will start. Choose a programming language and start learning.

As for teaming up with somebody, i don't encourage it. Not until you know what you're doing.

I really don't want to put you down, but you have to be realistic about these things. I started programming about 4 years ago (with a lot of breaks). Only now do i think that i am ready to build a *functional* and *complete* game. Even now, 5 months after starting my project, i am nowhere near done. Probably not even 10% done. Also, after 4 years, if you ask me what i think about game development, i will say this: It is NOT fun. Sure getting results can be awesome. But that only comes after months of pain and suffering Posted Image

So ask yourself the following question: Am I ready to spend years learning about game development?

#4950424 assimp nodes?

Posted by Waaayoff on 18 June 2012 - 05:29 PM

Find my answer in this thread. I explain how to do the animation, rendering and how to retrieve data from assimp. It also shows how you can overcome the problems mentioned in the above post :)

If you still have questions after reading it, i can answer them here.

#4948249 How to generate the elevation maps for GPU based geometry clipmaps?

Posted by Waaayoff on 11 June 2012 - 01:03 PM


I re-read the article after your answers and now it all makes sense Posted Image

Edit: If anyone's interested, i also found this article to be helpful: