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.

AppGameKit Classic Chat / [SOLVED] PBR Shader Request

Author
Message
MateiSoft
11
Years of Service
User Offline
Joined: 22nd Oct 2012
Location:
Posted: 12th Feb 2019 15:11
Hello forum,

Does someone has a PBR shader to send, for AppGameKit?

Thank you!
www.alexmatei.com

The author of this post has marked a post as an answer.

Go to answer

Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 12th Feb 2019 16:13
This post has been marked by the post author as the answer.
I think Preben has one in GameGuru Loader.

I've tried to make my own, but have failed miserably lol
MateiSoft
11
Years of Service
User Offline
Joined: 22nd Oct 2012
Location:
Posted: 13th Feb 2019 07:49
Alright!

Thank you!
www.alexmatei.com
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 13th Feb 2019 17:04
Here is a PBR shader I put together to test once.

I don't know what you're trying but you' probably won't get happy if you are try to make big scenes with this. (for now)
puzzler2018
User Banned
Posted: 13th Feb 2019 20:50 Edited at: 13th Feb 2019 20:52
We all have to think about CPU and GPU work and have a mutual level of companionship.

We dont want the CPU to do 1% of work and GPU to do 99% of work - cause over time, might as well say tata to your GPU card - and if its a laptop then WOW - Expensive burn out.

Make your CPU and GPU run at around 50% each

I wouldnt like my 2K laptop to be burnt out full of shader work n the next 5 years.
Tier 1 Developer
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Feb 2019 01:15
Em.....ok. I for one want my GPU to run at 100%, or damn near as close to it as I can get. What???
puzzler2018
User Banned
Posted: 14th Feb 2019 07:14
Ok. I still don't have a clue on how cpus and gpus work. Maybe they are specially designed to run at these lengths
Tier 1 Developer
MateiSoft
11
Years of Service
User Offline
Joined: 22nd Oct 2012
Location:
Posted: 14th Feb 2019 08:03
Janbo,

Thank you so much! How do I "compile" your shader? As .fx, or "vs" or "ps" ?

Thank you!
www.alexmatei.com
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 14th Feb 2019 14:04
Its a fragment shader you can name it PBR.fs for example or load the string directly vio the string.
Youl'l also need a vertex shader, for which you can take the default one, I think.
Leo Phoenix
14
Years of Service
User Offline
Joined: 24th Apr 2009
Location: South London, England
Posted: 14th Feb 2019 18:41
How do you use a fragment shader in AppGameKit?
andromedapps.com
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 14th Feb 2019 20:04 Edited at: 14th Feb 2019 20:08
@Leo: Hmm... You load the shader via file or string into AppGameKit using LoadShader() or LoadShaderFromString().
For the example of the PBR shader you'll need the vertex shader code too as its only the fragment part, to extract the Vertex code you could look here: Shader Guide which is a good read in general too.
Then if you don't care how the shader itself works you need to know what uniforms you need to pass via SetObjectShaderConstantByName() or SetObjectShaderConstantArrayByName().
So taking the PBR shader as example you'll see the first few lines, these are the textures youll need to pass as they are uniforms too.
And then there are the Lights Color, position and range which you want to set with SetObjectShaderConstantArrayByName(ShaderID,"LightPosition",LightID,LightX#,LightY#,LightZ#).
But if you don't want any hassle of this sort you can get my shader pack
(PBR shader not included yet)
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Feb 2019 21:59
Janbo,

Why are you using so many textures? You have 3 with it encoded into just the r channel, causing 3 look ups. If you encoded one to the r, one to the g, and one to the b and looked it up as a vec3 it would be quicker wouldn't it? From my playing texture look ups, especially on large textures, are about 60% of the speed loss, and I read that in modern systems vec4 is just as quick as a float.

Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 14th Feb 2019 21:59
Oh, and we don't pass textures as constants......they're loaded against the models.
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 15th Feb 2019 12:01 Edited at: 15th Feb 2019 21:40
Quote: "they're loaded against the models"

Not in AGK...Forgot to mention that, how could I think it would be obvius

Quote: "Why are you using so many textures?"
You are right, it's not polished yet, as implied above.
I think constant uniforms are combined to vec4 anyway, but not sure how its handeled in AppGameKit for textures... Maybe they check the amount of sampler keywords to alow for a new texture to load.
Would be possible, but yeah you are possible right
I do such things after everything works which isnt the case.
loading the texture takes some time for the cpu but acessing the swzzles of the sampler shouldn't cost much in return.
But yes texture samples are performance costly.
The short answer: there is no, exept of ease of use
So go ahead and combine the texture channels yourself
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 15th Feb 2019 13:55
I'm not going to use it, the overheads for PBR and the creation of media is waaaay beyond what I can manage by myself, I was more curious than anything as to if there was a specific reason for doing them singularly. I imagine hardware is a consideration, but on my 1080 texture look ups are very costly. I boosted speed for the landscape by having two textures, one a 4k, the other 12.5% of that (same file, loaded twice in AGK), and swapping between them based on fragment distance to camera. Distant textures get slightly blurry, but it increased the speed by about 60%. In fact, lpwwrr any texture size essentially increases speed, at least in pur opengl version.

Perhaps Vulcan will address this?

No idea how that works, but the less you have to look up a texture the better I've found.
Ortu
DBPro Master
16
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 15th Feb 2019 18:42
Quote: "I boosted speed for the landscape by having two textures, one a 4k, the other 12.5% of that (same file, loaded twice in AGK), and swapping between them based on fragment distance to camera. Distant textures get slightly blurry, but it increased the speed by about 60%. "


Isn't mipmapping supposed to be doing this automatically for exactly this reason?
http://games.joshkirklin.com/sulium

A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 15th Feb 2019 19:46 Edited at: 15th Feb 2019 19:47
Ortu,

I think a 4k texture has 16,777,216 pixels, whereas, a 512 texture has 262,144 pixels. So, even with mipmapping a 4k texture would be sampling far more texels than a 512 texture, as I believe the texel fetch is percentage based depending on LOD. At least, this is how I understand it.
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 15th Feb 2019 19:54
Quote: "Perhaps Vulcan will address this?"


Supposedly, we could use texture arrays now.

http://kylehalladay.com/blog/tutorial/vulkan/2018/01/28/Textue-Arrays-Vulkan.html
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 15th Feb 2019 23:26
I dont know the exact technical details, but picture how mip mapping works.

The gpu gets the 3d point, translates this into a texture x,y reference. But to blend it, it also has to get a bunch of other x,y references to know how to blend them. So mip mapping is slower. But, looking up a large texture takes longer. In my head in not sure why this is......it's like using a memblock.....you can pinpoj t any pixel in an image memblock as quickly as any other, and the size makes no difference. But for some reason a larger texture takes the gpu longer to look up.

So by having two sizes of texture, it's still mip mapping but mip mapping a smaller data set beyond a certain distance.
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 15th Feb 2019 23:38
This might explain some of it.....caching perhaps? Either way, I get a significant performnace boost using smaller textures on distant objects.

https://forum.unity.com/threads/texture-and-performance.133591/

Login to post a reply

Server time is: 2024-04-19 15:51:00
Your offset time is: 2024-04-19 15:51:00