Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / [STICKY] Learning to write Shaders

Author
Message
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 30th Mar 2009 21:20
Thank you Mr Handy. That's usefull about 3DSMAX. Round(x) is also usefull but its not exactly what i want. I want the decimal part not the integer.

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 30th Mar 2009 21:33
frac(x) is what you want.

Quote: "frac (DirectX HLSL)
Returns the fractional (or decimal) part of x; which is greater than or equal to 0 and less than 1.

ret frac(x)

Parameters
x
[in] The specified value.

Return Value
The fractional part of the x parameter.

Type Description
Name Template Type Component Type Size
x scalar, vector, or matrix float any
ret same as input x float same dimension(s) as input x

Minimum Shader Model
This function is supported in the following shader models.

Shader Model Supported
Shader Model 4 (DirectX HLSL) yes
Shader Model 3 (DirectX HLSL) yes
Shader Model 2 (DirectX HLSL) yes
Shader Model 1 (DirectX HLSL) vs_1_1"
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 00:54 Edited at: 31st Mar 2009 01:19
Ah yes, that's perfect Thank you GG!

With that i was able to tile the texture according to the terrains UV. Since the terrains texture tiled many times over on the terrain, UV's were not only values from 0-1 but could reach higher values and for UV(17.2, 19.5), for instance, i needed to turn that into UV(.2,.5) so that it sampled correctly coz UVW (17.2,-1,19.5) is not the same as (.2,-1,.5).

Here is the result.

I'm happy with it because of the learning experience that it was. Not as happy with the result because its as you said, the textures don't tile perfectly. If on some textures (dirt, for instance) seams are hardly noticeable, on other textures (marble, tiles etc)you can see the jagged edge where they tile. I realise the normal maps are not perfect. The tiles have inverted normals, and marble is not really bumpy but slick and shiny instead but these normal maps were created with the nvidia plugin for testing purposes.

I now know what I was doing wrong when i tried using many textures on the same bitmap instead of using a cube map like this time. Does that method have the same problem with the normal maps not tiling perfectly or would the result be better?

[edit]
Any idea why the seams are always there? Is because of the way cube maps are sampled using a direction vector that may not be as accurate as the 2d uv method?
[edit2]
Quote: "Yes - but you have that option anyway by putting several images side by side into one big texture and relying on the UV data to sort them out. The big problem with that approach is that you will get visible seams if you try to tile something like a terrain with one of the component sub-images."

Went back to your post and saw that the seams also happen on the ordinary side by side texture bitmap method :/ That sucks but as you say "food for thought (and experimentation) " some other day.

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 02:24
Quote: "Went back to your post and saw that the seams also happen on the ordinary side by side texture bitmap method"


The seams are there because of the "linear filtering" that goes on when a texture is sampled by the graphics card, i.e. when the UV coords "point to" a specific pixel (x,y) say, the graphics card actually uses some sort of average of the neighbouring pixels. This is fine unless you are on the edge of a texture. If you are using "wrap" addressing mode and the texture is "seamless" then everything is fine. However, in your case you are not on the edge of the texture as far as the GFX card is concerned, so it will sample from the neighbouring pixels, some of which belong to the next texture within the same image.

There is, if you think about it, a simple solution to this if you are working with "seamless" textures.

Quote: "That sucks but as you say "food for thought (and experimentation) " some other day."


Experimentation is the key to both learning and discovery.

Quote: "Any idea why the seams are always there? Is because of the way cube maps are sampled using a direction vector that may not be as accurate as the 2d uv method?"


Off-hand I'm not sure how the edges of the cube map are handled. I vaguely recall that seams showed up in one case unless I specified "addressU = clamp" and similarly for V and W. Another candidate for experimentation.

There is, however, another reason for seams in your demo which my earlier fixes didn't address. The set object normals command deals with each AT limb separately. This means that vertices along a common edge between two adjacent limbs will have two different normals associated with them, one for the left hand limb calculated using the vertices/polys to the left, and the second using the same data from the right. These two "average" normals will usually differ somewhat - and the lighting will enhance this effect from certain angles if the terrain is changing in slope as you cross the seam. The problem was very noticeable in some my earlier AT shader demos. The solution was to write my own routine for the normals which is now included in some of my AT shader demos.

As you say, there is time for all this "some other day".
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 13:23 Edited at: 31st Mar 2009 14:00
Quote: "There is, if you think about it, a simple solution to this if you are working with "seamless" textures."

Whenever i'm faced with a problem I tend to dream about possible solutions while sleeping (go figure how my brain works, trying to work instead of resting). Sometimes the solutions are ridiculous and an obvious result of being thought in a world where things happens as you see fit. Other times I actually ask myself if it isn't a good solution. So I tried a few options in my sleep and repeated them as soon as I woke up . First one was to make my own clamp directly in the texture. I manually reduced texture size (from 256 to 254), pasted it in the center of a 256 white bitmap and repeated the border pixels to fill the texture. Since i reduced the image to 99% of its original size, I scaled the UVW from [-1,v,1] range to [-.99,v,.99] range. The problem persists Then I went a bit more extreme and scaled UVW to [-.1,v,.1] thinking there is no way it samples from the neighboring textures in such a small range but the problem is still there. So I don't think its sampling the neighboring textures. I set the sampler_state of min, max, magfilters to none and there are no seams when there is no mipmapping (although the terrain sparkles everytime the camera moves for obvious reasons). I went to HLSL reference on the microsoft site to read the description of the linear texture filter type:
Quote: "D3DTEXF_LINEAR
Bilinear interpolation filtering used as a texture magnification or minification filter. A weighted average of a 2 x 2 area of texels surrounding the desired pixel is used. The texture filter to use between mipmap levels is trilinear mipmap interpolation. The rasterizer linearly interpolates pixel color, using the texels of the two nearest mipmap textures. "

Can it be sampling that from the lower mipmap level textures :/

Can't think of anything else. I attached the updated project so u see exactly what i'm talking about. Press +/- to scale the textures but notice how those darn pixels between the tiles are always there. To see the best example find the patch of terrain that has a marble texture on it. On whiter areas the effect is more obvious.

Quote: "There is, however, another reason for seams in your demo which my earlier fixes didn't address. The set object normals command deals with each AT limb separately. "

Oh I knew this. I was talking specifically about the seams between each texture not on the limbs. That can be fixed with "some" ease so i'll leave it for later.

[edit]
Geometrically speaking i know what a normal is. I searched the web looking for descriptions of the binormal and the tangent and found a lot of very detailed mathematical expressions using derivatives and gradients etc and i think I got the gist. From what I understand they always form 90º angles between each other correct? The normal is perpendicular to the plane created using the binormal and tangent. Tangent is perpendicular to the plane created using normal and binormal, and binormal is perpendicular to the plane created using the normal and tangent.
In normal mapping (and other techniques i suspect) do we create the TSM matrix to serve as a kind of local axis for each face to transform the light vector according to the normal map?
Ok enough questions. This post is getting huge and i promiss I won't ask anything else until these questions are answered.

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 13:59
Quote: "I manually reduced texture size (from 256 to 254), pasted it in the center of a 256 white bitmap and repeated the border pixels to fill the texture. Since i reduced the image to 99% of its original size, I scaled the UVW from [-1,v,1] range to [-.99,v,.99] range."


That is exactly the simple "solution" I had in mind.

But, as you've discovered, it doesn't deal with the effects of mipmapping which was something I'd overlooked. I suspect you've hit the nail on the head there. I encountered something similar in a different context and the problem disappeared when I manually altered the edge pixels of each mipmap.

I'll look at your demo later and put my thinking cap on again (if I can remember where I put it ).
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 14:02
Quote: "From what I understand they always form 90º angles between each other correct? The normal is perpendicular to the plane created using the binormal and tangent. Tangent is perpendicular to the plane created using normal and binormal and binormal is perpendicular to the plane created using the normal and tangent."


Yes.

Quote: "In normal mapping (and other techniques i suspect) do we create the TSM matrix to serve as a kind of local axis for each face to transform the light vector according to the normal map?"


Yes.

Sounds like you are making excellent progress getting to grips with this stuff.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 14:04 Edited at: 31st Mar 2009 14:16
I did try to alter the edge pixels of each mip map but its a cube map and for some reason i can't load it properly with the mipmaps on photoshop. Here is what i get:

see how the textures are split in half.

[edit]
now i have the proper image i wanted for some reason i kept uploading the actual cubemap

I'm glad i'm finally understanding this stuff. I'll only be happy when i understand exactly how evolved puts all his shaders working so perfectly together. He adds a normal mapping shader to an object and then loads a light shader (don't know what he applies it to) and the lights affect the normal mapped object O_o Its like he can put more then one shader in each object.

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 14:33
Quote: "I did try to alter the edge pixels of each mip map but its a cube map and for some reason i can't load it properly with the mipmaps on photoshop. Here is what i get:"


Not sure what you mean? Do you mean PhotoShop won't save the cube map with mipmaps or DBPro won't load them or PhotoShop won't load them or what? Your image shows the mipmaps - what application was that?

Actually, you've taught me something today. I didn't realise that cube maps could have mipmaps till I looked at your cube.dds image more closely.

I've got to leave this now but I'll have a look later. It's certainly an interesting problem.

Just to make doubly sure we're on the same wavelength here, could you post a screenshot showing the seams we're trying to fix?
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 15:06 Edited at: 31st Mar 2009 15:09
Photoshop won't load the mipmaps correctly. The image i posted is what photoshop loads. I'll try installing and loading it on gimp l8r.
What did u use to notice mipmaps in my cubemap? Can i use that to edit the mipmaps
Since we set the sampler state to include mip, mag, min filters i always assumed it could have mipmaps but what confirmed it for me was being able to select what mip level to see of the cube map in the textures tab of FX Composer.

Look at the seams I'm talking about. As you can see in pic the exact same location but 3 diferent UV scales.

By seams i don't mean that the textures don't tile perfectly i mean that pixels are rendered around each "tile" of each texture. Like a frame.

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 15:22
Quote: "What did u use to notice mipmaps in my cubemap?"


DxTex.exe - this is a simple utility that comes with the MS DX9 SDK. If you haven't downloaded it yet then do so. It's free and full of useful documentation and examples.

Quote: "Can i use that to edit the mipmaps"


Not directly. I think I used MS Paint ( ) to edit the individual maps and then used DxTex to replace the original mipmaps.

Quote: "By seams i don't mean that the textures don't tile perfectly i mean that pixels are rendered around each "tile" of each texture. Like a frame."


I think I understand.

Do you get the same problem with a simple DBPro plain? If so then that would simplify the task of investigating the problem.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 16:56
Quote: "Do you get the same problem with a simple DBPro plain? If so then that would simplify the task of investigating the problem. "


Yes. Exact same thing on the plain. What does that tell us? It is not a problem of the terrain. Anything else?

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 17:01
Quote: "What does that tell us?"


Nothing - except that we don't need all the extra clutter of AT to wade through while solving the problem.

Quote: "Anything else?"


I'm thinking about it.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 20:23 Edited at: 31st Mar 2009 20:30
I found the problem. Its with the frac() command.
I decided to alter the shader so that instead of reading a texture from a cubemap face and the normalmap from the same face of a second cubemap, it loads 6 textures with the normalmap on its side like here. (sorry i'm lousy at explaining something in english but i hope that u see what i mean from the texture)



So i ignored the normal map for now and tried to tile the colormap on the terrain and i used the following

This reconstructs the uv to (u/2,v). I was expecting a seam on one direction of the texture since i was cuting the texture in two on the horizontal side but i was really surprised to see seams on all sides of the tiles. So i recalled i used frac on both the u and v coordinates. So i tried it without the frac on the v coord and indeed there was only one seam repeated on the terrain where the texture was being cut.

So maybe that settles what is causing the problem, but not how to solve it. I've been trying a few things but nothing seems to work. What exactly can the frac() command be causing? Inaccurate rounding of the value? But even so it would just be another very proximate UV coordinate so why does it display such an obvious seam :/ I'm at a loss. Frac me

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 21:10 Edited at: 31st Mar 2009 21:33
I'll try that and post back with my thoughts. It's good that you've narrowed it down to something simple.

Edit

OK. Just tested that image with your idea in DarkShader and confirmed what you've reported, i.e. with "frac" you get a seam on all four sides (you'd expect only two - the ones with the normal maps), without frac on the "y" coord you get the correct seamless tiling on two of the edges.

I don't have answer at the moment. Food for thought.

I'll try again later using the "simple solution" we discussed earlier (I haven't actually tried that myself yet).

I'll edit this post again with the results.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 21:22 Edited at: 31st Mar 2009 21:33
Yeah its so so simple that I even have the feeling that its unfixable since i really need the frac there hmmmm idea
Meh, failed.


Isn't frac(IN.UV1.x)/2 the same as ((IN.UV1.x)-trunc(IN.UV1.x))/2
I think it is but my terrain disapears with this trunc expression. So i'm fresh out of ideas

[edit]
What the hell is wrong with the trunc function. It IS a valid function that returns a float according to the HLSL reference but even if i add an innocent "float UV1=trunc(1.6);" and don't event reference it anywhere my terrain disapears.
Quote: "
ret trunc(x)
Parameters

x

[in] The specified input.

Return Value

The input value truncated to an integer component.
Remarks

This function truncates a floating-point value to the integer component. Given a floating-point value of 1.6, the trunc function would return 1.0, where as the round (DirectX HLSL) function would return 2.0.
Type Description
Name Template Type Component Type Size
x scalar, vector or matrix float any
ret Same type as input x float Same dimension(s) as input x"


I can't see what is wrong with this code coz yesterday my windows crashed and lots of programs and even windows components were corrupted including the windows installer. FX Composer fails to open and i can't install again coz windows installer is corrupted I'm still waiting for my HDD to come back from the repair shop and this USB drive is proving rather flimsy to hold an OS.

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 21:40 Edited at: 31st Mar 2009 21:46
Quote: "What the hell is wrong with the trunc function. It IS a valid function that returns a float according to the HLSL reference but even if i add an innocent "float UV1=trunc(1.6);" and don't event reference it anywhere my terrain disapears."


I can't find it in the documentation. Did you mean "floor()"?

Your terrain disappears because your shader won't compile.

Dark Shader throws up an error immediately (as would FX Composer I expect).

Edit Yes. FX Composer throws an error as well. What documentation are you quoting?
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 21:56
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 22:33
That is very interesting.

Suggests they've extended the HLSL language somewhat. I haven't got the latest SDK. When I've got a few minutes I'll test it to see if it has an updated shader compiler, "fxc.exe" I think.

Interestingly, the documentation isn't clear whether it truncates towards zero or downwards (like floor()). I guess it's the former - assuming you can get it to work.

Anyway, you want the floor() function.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 31st Mar 2009 22:48 Edited at: 31st Mar 2009 22:54
Quote: "Interestingly, the documentation isn't clear whether it truncates towards zero or downwards (like floor()). I guess it's the former - assuming you can get it to work. "


Actually it does. If u read it carefully you'll find

Quote: "Given a floating-point value of 1.6, the trunc function would return 1.0, where as the round (DirectX HLSL) function would return 2.0."


Quote: "Suggests they've extended the HLSL language somewhat. I haven't got the latest SDK. When I've got a few minutes I'll test it to see if it has an updated shader compiler, "fxc.exe" I think."

What does that mean? If they have extended the language will DBP not be able to compile that command or does DBP use the "fxc.exe" to compile so updating fxc would fix that.

Quote: "Anyway, you want the floor() function. "

LOL i read that command description in the msdn HLSL reference and I thought that wasn't what I wanted but I see now that it has rather conflicting information.

Quote: "
floor (DirectX HLSL)

Returns the largest integer that is less than or equal to the specified value.
ret floor(x)
Parameters

x

[in] The specified value.

Return Value

The largest integer value (returned as a floating-point type) that is greater than or equal to the x parameter."


I guess they also suffer from the copy-paste syndrome at microsoft.

[edit]
Moving on. (IN.UV1.x-floor(IN.UV1.x)) is exactly the same as frac(IN.UV1.x) so the seam is still there

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 31st Mar 2009 23:16
Quote: "Actually it does. If u read it carefully you'll find


Quote: "Given a floating-point value of 1.6, the trunc function would return 1.0, where as the round (DirectX HLSL) function would return 2.0.""


I did read it carefully. What about -1.6? Is that truncated downwards towards -2 as in floor(x) or upwards towards 0? What do you think and why?

Quote: "I guess they also suffer from the copy-paste syndrome at microsoft."


Yes indeed.

Perhaps the trunc() function is described in the update information somewhere - but which update? I'm using the November 2007 SDK on both my machines. I'll try to remember to get the latest when I'm at work tomorrow (takes too long to download here ).

Quote: "Moving on. (IN.UV1.x-floor(IN.UV1.x)) is exactly the same as frac(IN.UV1.x) so the seam is still there"


Yes it is.

I'm going to do some simple tests with textures which have black pixels along one edge and white along the other to see what happens.

It would be good to have a solution to this problem.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 1st Apr 2009 00:19 Edited at: 1st Apr 2009 00:26
Well, er coz teacher said so When i was in high school (way back when) my computer science teacher taught me that truncating a float meant to cut off the decimal part. There is no rounding happening. That's what happens in basic when u turn a float into an integer. The decimal part is truncated. So that is what stuck on my mind. I realise that microsoft may have used the meaning it wanted and made a function that does something else but if they went with one of the meanings of the verb truncate then it should do as I explained.

http://www.merriam-webster.com/dictionary/truncate

One of the meanings of the verb truncate is to "shorten by or as if by cutting off".

And makes sense that it does cut off the decimal part otherwise it would be the same thing as floor() and there is no point having different functions do the same thing.

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Apr 2009 00:25
OK. Done some experimenting. The only way I can get rid of those seams using your original texture "tex4.jpg" is to turn off all the filtering in the shader, e.g.:



This isn't very satisfactory because the whole object gets "pixelated" and "shimmers" as you move it in the scene. But you don't get seams.

This may suggest that it's the filtering that's the problem not the frac command (but then why is the problem not present without the frac command?). I'm still rather baffled. I'll have to consult The Oracle.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 1st Apr 2009 00:30
Yeah that is also the only way i found of getting rid of the seams on the cubemap version of the shader No other filtering mode helps.


U mean this Oracle?

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 1st Apr 2009 01:27
Quote: "U mean this Oracle?"


Certainly worth a try.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 3rd Apr 2009 22:02 Edited at: 3rd Apr 2009 22:16

The strangest thing is happening. I manually wrote line 2 of the pic and my shader did not compile. I thought i had finally reached the instruction limit but i can't be sure coz FXComposer still doesn't work on my computer. To be sure I then copy pasted another line and turned it into line 1. So they are the exact same thing. But it compiles well if I comment out line 2 and keep line 1. If I comment line 1 and keep line 2 it still doesn't compile. lol I don't have a question but just had to share this weirdness.

[edit]
Argh! Better call it a day today. It's not the day to continue venturing into shaders every little change breaks the shader :/

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2009 22:12
Quote: "So they are the exact same thing."


No, they're not. Look again.

By the way, with Paul Johnston's invaluable help, we may have a solution to your "seams" problem. If you're still interested I'll post a demo.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 3rd Apr 2009 22:18 Edited at: 3rd Apr 2009 22:28
OMG How did i not see that GRR!!! I even double (tripple) looked to make sure i wasn't posting a stupid remark. I guess my dislexia is at a maximum today.

Ofc I am interested in a demo to get rid of the seams I am still working on the terrain, adding some stuff (lightmap) just waiting for the solution to that problem. I was even going to email him myself thinking you hadn't had the chance to.

[edit]
Regardless of the result why does this compile?
Quote: "Out.colour = baseColour +(ambiColor + diffuse * lightColor)+(specular * lightColor) ;"

Why does this compile?
Quote: "Out.colour = (baseColour) * Light_Color;"

But not this?
Quote: "Out.colour = ((baseColour) * Light_Color)+(ambiColor + diffuse * lightColor)+(specular * lightColor) ;"


Note:Light_Color has been initialized earlier with " float4 Light_Color = tex2D( LMSampler ,In.UV0 );" and lightColor and Light_Color are not the same thing and its not a typo

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2009 22:38
Quote: "Ofc I am interested in a demo to get rid of the seams I am still working on the terrain, adding some stuff (lightmap) just waiting for the solution to that problem."


I'll see what I can do. How complicated do you want it to be? Just a simple demo of the basic idea or a full-blown terrain using a "texture atlas" with 16 component textures plus bumpmapping and roads?

The key to the problem was to take control of mipmapping by using three intrinsic functions that have probably not been used in this thread before: ddx(), ddy() and tex2Dgrad() (although MrHandy did ask about the first two - so he at least should pay attention and study the demo).

I've also checked out the "trunc()" issue. I installed the November 2008 MS DX9 SDK on my work machine and it too included the "trunc()" intrinsic in the documentation. But, even the utilities which come with the SDK won't accept that function. So it looks like the "cut and paste dragon" is working overtime at MS yet again.

My theory is:

(a) the trunc() function is not a figment of someone's imagination;

(b) it is probably a new function for one of the more recent shader models (SM4 perhaps) and was listed as SM1 and SM2 compatible by mistake.

I look forward to someone showing me a PS1 shader which compiles and uses that function.
MIDN90
15
Years of Service
User Offline
Joined: 11th Mar 2009
Location: Colville, Washington
Posted: 3rd Apr 2009 22:54
Good stuff.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 3rd Apr 2009 22:55
Well I can do with a demo of the basic idea to sort out my own shader. I wouldn't mind seeing a full blown terrain using 16 textures plus bump mapping and roads If you decide to do the full blown shader it'll probably take a bit so can u give me a few lights on how to solve my own problem coz i'm really curious.

So... forget the trunc() until DBPro X10. Got it!

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2009 22:58
Quote: "But not this?"


I have no idea.

What compiler are you using? It should give you error messages. Have you got Dark Shader?

Post the whole shader and it should take a few seconds to track down the problem. An obvious possibility is that you've hit an instruction count limit. If that's possible then try compiling with PS_2_a instead of PS_2_0 (assuming your card supports PS2a of course ).
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 3rd Apr 2009 23:00
Quote: "Well I can do with a demo of the basic idea to sort out my own shader."


Will do - but not tonight.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 3rd Apr 2009 23:07
NOOOOOOOOOOOOOO!!!!!! You can't tease me like this!! This feels like the cliffhanger from a tv series season finale

On the other hand I still have my school project to finish and it's due tomorrow at 23:59 so maybe I should focus on that.

Take care
AtomR
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 11th Apr 2009 01:13 Edited at: 11th Apr 2009 01:38
I finally got my hard drive back and reinstalled my system from scratch and everything seems to be working ok now including FX Composer. With FXC i was finally able to see why my terrain shader doesn't compile when i simply add a new color to the final color of the pixel. My pixel shader exceeds the maximum commands allowed X_X
Easily fixable by replacing "PixelShader = compile ps_2_0 PShader();" with "PixelShader = compile ps_2_a PShader();" which suits me just fine. But I'm still left wondering how i could overcome that if my graphics card didn't support 2.a. I suppose that I could check all lines in my shader and see what could be simplified. Failing that would be to use more then one pass if I'm not mistaken. How could I do that?

Would I need to have two methods/functions, for instance PShader1 and PShader2, and have PShader1 receive the VShader's output data and PShader2 receive PShader1's output data? Is that how it works? Coz i tried that and it wouldn't compile saying that "Can not convert from Struct PSInput to struct PSoutput".

Take care
AtomR
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Apr 2009 02:05
Quote: "I suppose that I could check all lines in my shader and see what could be simplified."


You could - but unless you've done something obviously wasteful my experience is that it is hard to fool the FX compiler. It already has an optimiser built into it - it can detect some things which are unnecessary and changes the compiled code accordingly.

Quote: "Another method would be to use more then one pass if I'm not mistaken."


Yes - that's often used for things like adding several lights.

Quote: "How could I do that?"


Look for parts of the code where several things have been added together to give the final colour (such as lights). Put some in one pass and the rest in another. If you mean "how do I set up the shader with several passes?" then it would look something like the following:



It isn't essential to have different vertex or pixel shaders - for example in some applications you could use the same ones but called with different arguments, or in another you might use the same vertex shader code. Similarly, you might have the same input and output structures.

If you are adding several things together then you need to add the following lines to the second and subsequent pass blocks:



as in the following simple example:



Before running the code see if you can work out what the final result should look like.

By the way, I'm aiming to put together a simple demo of the solution to the seam problem some time this weekend.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 11th Apr 2009 02:28 Edited at: 11th Apr 2009 02:31
Thanks for that explanation on how to setup a shader with multiple passes. Its odd though that when i tried to make 2 passes i did like in your last example where i had only 2 structs, 1 vertex shader method and 2 Pixel shader methods. I'll try again tomorrow coz it's late and i have a spliting headache

Before i go, and regarding the seam problem, i spent the last hour trying to see if I could get rid of the seams by using the ddx(), ddy() and tex2dgrad(in my case texCUBEgrad) and i did but am not sure if i'm doing it right. I stripped down my terrain shader to just use one texture for the sake of simplicity and here is what I got.

Quote: " PSOutput PShader(PSInput In, PSOutput Out)
{
float Temp_UVx= frac(In.UV1.x);
float Temp_UVy= frac(In.UV1.y);
float3 UVW1 ={temp_scale*((Temp_UVx*2)-1),1,temp_scale*((Temp_UVy*2)-1)};
float4 Temp_map1=texCUBEgrad(cubeSample, UVW1,ddx(In.UV1.x),ddy(In.UV1.y));
Out.colour = Temp_map1;
return Out;
}
"

Here is the result.

Seamless but for each 'tile' you can see the texture gradually using a diferent mipmap level. That has 3 unpleasent effects.
1. as u can see in the pic, altho the texture tiles, you can see even in the distance that its using a higher quality mip map then it should.
2. because of point 1, one corner of the tile always 'shimmers' in the distance.
3. on my 6 texture+bump mapped terrain shader FPS goes from 100 to 30 X_X

Enough of this for today I need to lie down and sleep off this headache. Talk to you tomorrow.

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Apr 2009 02:47
Quote: "Enough of this for today I need to lie down and sleep "


Ditto.
MIKE maho
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location:
Posted: 11th Apr 2009 11:12
Hi! I need some 3d-math help

This is example how to re-create world-space position in camera from depth. But It comes as is, with no explanation. Can you explain this code? Or maybe there is other way to calculate world-space from depth.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Apr 2009 12:49
Quote: "Before i go, and regarding the seam problem, i spent the last hour trying to see if I could get rid of the seams by using the ddx(), ddy() and tex2dgrad(in my case texCUBEgrad) and i did but am not sure if i'm doing it right. I stripped down my terrain shader to just use one texture for the sake of simplicity and here is what I got."


That's more or less how I had to do it.

I'm not sure about the other problem - I'd probably need to see the code and also see the thing running. Two things occur to me:

1. make sure you've got all three filters set to linear;

2. try multiplying ddx and ddy by a constant greater than one, i.e.



and try setting the float "factor" equal to 2, 3, 4, etc. This will make the GPU think the texture is further away so it will use a lower resolution mipmap. It's possible the default behaviour using the usual tex2D instruction does something like that anyway - but I don't know, detailed documentation on such things is impossible to find.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 11th Apr 2009 15:02 Edited at: 11th Apr 2009 15:04
I did what u suggested and that accentuates the problem but also allowed me to reach some conclusions on where the problem might lie.

Every tile of the texture has from nearest to farthest mipmap level. Probably because I am using the partial derivative of the uv coordinate. So UV 0,0 is the nearest and 1,1 is the farthest. In the pic i'm using factor=5.

I suppose i should be using world coordinates to determine the distance :/ This is where I don't have a clue. What space should i be using. World, View, WVP, WV, P X_X
From my (probably) faulty reasoning i'm thinking worldview. Since for mipmap what matters is how far the pixel being drawn is from the camera. But I've tried everything and nothing worked :/

Take care
AtomR

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Apr 2009 15:18
Quote: "I did what u suggested and that accentuates the problem"


Hmm? Your screenshot is puzzling - it suggests that the low res screenshots are being used close to the camera whereas the high res ones are being used far from the camera.

Aah! Just noticed that you are using a CUBE map and CUBE texture look-up - I was thinking of the usual 2D texture functions "tex2D" and "tex2Dgrad". I have no idea off-hand how the "texCUBEgrad" function works - and can't immediately see why the "texCUBEgrad" function would want just the UV coords and not W as well. Any particular reason for using a cube map for this? Why not a simple 2D texture split into component images? Or have I forgotten what you're trying to do?

Sorry about the confusion on my part.
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Apr 2009 15:27
Quote: "Can you explain this code?"


No.

Quote: "Or maybe there is other way to calculate world-space from depth."


You can't. You need three coordinates in order to do that, depth, i.e. distance from the camera, is only one of the three that you need.

You could if the variable "pos" contained the required additional information - but that snippet doesn't give any information about it.
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 11th Apr 2009 15:35 Edited at: 11th Apr 2009 15:41
Since I already had the shader done to use cubemaps I continued using it. It shouldn't take long to use 2dtex. However regardless of where I have my camera that result doesn't alter so it isn't showing lower res textures nearer to the camera. But in that screeshot I was still using UV coords on the ddx, ddy components of texCUBEgrad.

I have since then tried using world, worldview, and other spaces but the result doesn't change much.

Quote: "
Why not a simple 2D texture split into component images? Or have I forgotten what you're trying to do?"


You haven't. I'm just trying to learn and maybe i'm going the hard way around everything but i supose in the end i'll understand more how this shader things work

Take care
AtomR
MIKE maho
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location:
Posted: 11th Apr 2009 16:17
I've figured out that code was re-creating camera-space coords from depth, not world-space

All i want is just make 1 world-pos pass instead of 2 in old Evolved deferred shading. At first i set word-pos cam to rgba 32bit float, and thought that would be enough to store all 3d data, but shader wont use this texture - lighting becomes buggy.
Maybe shader need some tweak?

Evolved original shader attached.

thank you

Attachments

Login to view attachments
Green Gandalf
VIP Member
19
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 11th Apr 2009 16:56
Quote: "You haven't."


I'll believe you.

Quote: "But in that screeshot I was still using UV coords on the ddx, ddy components of texCUBEgrad."


Yes, I know. But the point is that CUBE texture look-ups work rather differently - they use the UVW vector as a direction vector pointing from the hypothetical center of the cube to its surface. The texture pixel at the point of intersection with the surface is the pixel of interest. It's been a while since I tested this but I think I'm right in saying that multiplying the UVW vector by an arbitrary positive constant doesn't change the pixel value returned - since it corresponds to the same direction. How this relates to the use of ddx and ddy I'm not sure. I'll have to do some homework.


Quote: "maybe i'm going the hard way around everything but i supose in the end i'll understand more how this shader things work"


It is the hard way for this particular problem - but I agree it's things like this that force us to fully understand how things work. So I'm happy to pursue this with that objective in mind.
MIKE maho
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location:
Posted: 11th Apr 2009 17:09
Oh it seems to be i have just messed up texture names. Everything ok now, thanks anyway!
AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 12th Apr 2009 14:58
I'm going around in circles. Everything takes me back to the same place. I've managed to make a shader with the ddx/ddy/texCUBEgrad work well(ish) with most seams gone except for those in 1 texture stage (go figure) but only if compiled as PS3.0. Moreover the same code that produces the cool bumpmap as ps2.0 (your code GG) becomes very metalic as PS3.0.

What would make a shader with
" VertexShader = compile vs_2_0 VShader();
PixelShader = compile ps_2_a PShader();"
compile properly on FXComposer but when running in DBPro make the object disapear?
AND when i change the same shader to
" VertexShader = compile vs_2_0 VShader();
PixelShader = compile ps_3_0 PShader();"
Copiles on both FXC and DBP.

It's an easter riddle. Happy easter. I can't provide any code coz i'm in a rush for lunch

Take care
AtomR
Math89
20
Years of Service
User Offline
Joined: 23rd Jan 2004
Location: UK
Posted: 12th Apr 2009 18:16
This function may save you hours of debugging :


It simply displays the compilation errors that occurred during the loading.

AtomR
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Portugal
Posted: 12th Apr 2009 22:28 Edited at: 12th Apr 2009 22:29
Thanks Math89, that is very useful I still don't know why the error that was reported by that function wasn't reported by FXComposer but at least there is a way to know compiling errors from within DBP which i didn't know.

By commenting out pieces of code I managed to narrow the error down to one very important but (apparently) very inconspicuous line.
Quote: "Out.colour = baseColour;"

both are float4 but i get the following nonsense about swizzling.


Take care
AtomR

Attachments

Login to view attachments

Login to post a reply

Server time is: 2024-11-24 09:40:55
Your offset time is: 2024-11-24 09:40:55