CrateDemo_executable

This demo takes the procedural box from 'GeometryGenerator' and uses the custom shader 'Basic.cpp' to apply a crate texture ('WoodCrate01.dds') to it.
The 'Basic.cpp' custom shader currently supports transformations, lighting, and texturing. It will act as the basic template for the still-to-come shaders.

However, it also demonstrates how to apply different Techniques to the shader from within the C++ code. By supplying different parameters to the function 'TechniqueCustomShaderName()', the shader can be compiled so that it will behave according to how those parameters are used in the shader code.
Esenthel has made this possible by means of a 'CUSTOM TECHNIQUE' macro replacing the usual 'TECHNIQUE(Main, VS(), PS())' which I've been using until now.

Observe that 'Basic.cpp' has techniques with texturing and without, by using the uniform parameter 'gUseTex'. In this way, if I need to render something that does not need texturing, I select the technique without it, and therefore, do not have to pay the cost of texturing . Likewise, I select the technique with the number of lights I use, so that I do not pay the cost of additional lighting calculations that I do not need.

My first post has been updated with the latest project files.

Yet again, many thanks for the continued examples.

Got my copy of the book today too

@pixelperfect

Quote:Got my copy of the book today too

That's great! You can only gain by going through it. Although specifically applied to DirectX 11, it does not matter too much as all the DirectX 11 stuff is already encapsulated in Esenthel.

Just an added note on the 'CrateDemo' I posted yesterday:
I had left the 'myTexTransform' matrix just as an identity matrix, but there is nothing stopping folks putting this matrix to use:
For tiling the texture, just add some scaling by adding in the 'Init' section:

For animated scrolling of the texture, add in the 'Update' section:

For animated rotation of the texture, add in the 'Update' section:

if built in 64bit the program becomes unresponsive for me, can anyone else verify?
32bit build works fine.

The problem seems to be occuring at "myWater.parts(0).render.vtxUnlock(); // NB unlock after all read/write is completed"

due to a EE::Free call inside VtxBuf unlock.

I think he only intended it 'as it is' to be for 32 bit build as mentioned in his opening post:

(11-21-2014 10:20 AM)3DRaddict Wrote:  Just a few notes on the project requirements:
1) Only Windows 32bit
2) Only DirectX 10+
3) For the shaders to compile you must duplicate my particular setup (or change to suit your own)

I have had an issue with running this which resulted in a run time error indicating the AO buffer already existed by with a different size. Removing the Ambient Occlusion shader header cured this so I guess I might have an out of date copy of the shader headers.

yes I know of the notes, however the behavior of the program shouldn't differ like that unless there is something I am missing. This obviously is only on Lightning tutorial due to that exact call, and it is the only problem I've encountered.

the AO issue certainly is because of outdated shader headers. you can fix that by removing the // before CompileShaders in the lightning tutorial. if that doesn't help, you might as well update to latest shader headers as there is nothing to gain keeping the old ones. : )

---

The place where you are doing something wrong regarding elongated droplets is in



found it by doing the way slower approach of

my guess is possibly the NrmTobyte or the offsets are wrong.

(11-30-2014 06:33 PM)Zervox Wrote:  ...
the AO issue certainly is because of outdated shader headers. you can fix that by removing the // before CompileShaders in the lightning tutorial. if that doesn't help, you might as well update to latest shader headers as there is nothing to gain keeping the old ones. : )

Yeah, I'll update the shader headers ... thanks.

(11-30-2014 06:33 PM)Zervox Wrote:  yes I know of the notes, however the behavior of the program shouldn't differ like that unless there is something I am missing. This obviously is only on Lightning tutorial due to that exact call, and it is the only problem I've encountered.
...

Thinking about it the restriction to 32 bit in the notes may only have been due to the initial Windows dependencies, there may have been a 32 bit lib referenced. I don't remember what was referenced since those dependencies were removed.

@Zervox

Quote:The place where you are doing something wrong regarding elongated droplets is in

Thanks for pinpointing this... I substituted your bit of code and, lo and behold, I have nice circular ripples!

I'll have to investigate my dynamic vertex buffer code to see where it is going wrong.

As for the 64-bit story... it really boils down to my "old habits, die hard" theory.
Even though I have 'Windows 7 Home Premium' installed, I've grown too used to installing all apps and my own code projects in 'Program Files (X86)' folder as 32-bit.
Just never bothered with changing over to 64-bit.

I, just now, tried compiling all these shader examples as 64-bit, and you are quite correct, Zervox, they all compile and run ok, except 'Lighting'. I've no idea why.

Anyway, as I mentioned in my preamble to this project, I was undertaking it purely on a personal training basis, and just providing my code for others to view as they please. As long as it works on my particular system, I'm happy.

Debug directs toward the unlock operation done at the end, something in the unlock is calling free, and that code is the code which is doing something it maybe isn't supposed to. Maybe EE could have a look at it when he gets time, I could possibly check it myself but I also got other things on my plate at the same time.

Yes and thank you anyways, because even if that exact sample doesn't work, I don't expect you to cover every grounds of platforms 32bit and 64bit compatibility. It still does give some ideas to try out. whatever I find not working on 64bit I might try writing code myself that works for both. it is good exercise in and by itself. ^^

My ripple problem has been solved!

http://www.esenthel.com/community/showth...8#pid49718

Looking awesome.

Just wanted to note the fix for the ripples fixes the crash for 64bit.

Just added a little bit of life in the form of a tiled 'grass' texture and a tiled scrolling 'water' texture. The water now has circular ripples. Two custom shaders 'basic_land.cpp' and 'basic_water.cpp' take care of transformations, lighting and texturing of the land and water, respectively.


TexturedHillsWavesDemo_executable

Worked hard on completing the 'BlendDemo' today, but no real problems.
Three more custom shaders 'basic_land2.cpp', 'basic_water2.cpp' and 'basic_box2.cpp' were added.

These shaders incorporated two more Technique parameter options: 'gAlphaClip' and 'gFogEnabled'
This increases the number of Technique choices significantly... one can now compile the shaders with 1,2 or 3 directional lights, texture or no texture, alphaclipping or not, fog or no fog (see the 'CompileShaders()' function in the code)

Added a transparency parameter ('water_AlphaFactor') to the 'basic_water2.cpp' shader to control the amount of water transparency required


Added a wire cage box with a 'WireFence.dds' alpha texture.


When 'gAlphaClip' is set then the intrinsic HLSL function 'clip(x)' is activated.This function can only be called in a pixel shader,
and it discards the current pixel from further processing if x < 0.1, where x is the current pixel's alpha value.

I noticed that the inside back face of the box cage was not showing. After perusing the EE documentation I found that the Material applied to a mesh controls, via the Material '.clip' method, whether the back faces of meshes are clipped or not. The default is 'true' (clipping applied). So I set it to 'false', and I could then see the backside of the wire cage through the front face.


The final addition to this demo is the activation of fogging in the pixel shader, depending whether 'gFogEnabled' is true or not.
This makes use of the HLSL 'lerp()' function which blends the fog color in with the water, land and box colors according to camera distance from the current pixel.
The following shader fog parameters can be set in the 'Main' code and passed down to the shaders.
Flt gFogStart;
Flt gFogRange;
Vec4 gFogColor;


Sky background set to same color as fog, so that fog blends in with the sky.

BlendDemo_executable

Wow! You're churning these out at a great rate of knots! Many thanks again, really appreciate this series of tutorials/illustrations. I'm hoping I will eventually be able to put the knowledge you are imparting to good use