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/AppGameKit Studio Showcase / Last Evening at the PBR Sphere Garden Party

Author
Message
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 26th Oct 2019 04:19 Edited at: 26th Oct 2019 04:22
Spheres just want to have fun.
There is absolutely no point to this demo other than that I wanted to try this approach to rendering at a semi-high quality. Best watch fullscreen, it's 1080p/60

PSY
Valued Member
3
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 27th Oct 2019 14:13
Man,

that's a lot of spheres at that party. Hope you got enough to drink ^^
VERY impressive demo. I'm a sucker for spheres...
You mind sharing a few words about how you made it and what you used?


PSY


PSY LABS Games
Coders don't die, they just gosub without return
Captain Ouais
16
Years of Service
User Offline
Joined: 12th Dec 2003
Location: France
Posted: 27th Oct 2019 16:09
It is useless but it's nice !
I do what i do !!!
Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 27th Oct 2019 20:38
How much of it is pre-baked?
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 27th Oct 2019 22:57
Nothing. Both lights are moving anyway, so in this case it didn't make sense to do it.
Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 27th Oct 2019 23:59
Wow......that's all realtime? That's stunning, and quite miraculous speed.

How did you do the shadows? I notice there are two casting light sources in the video, and the shadows are absolutely perfect and have some form of depth based softening and diffusion going on?

The teolustion on the spheres also appears to be super high by how perfect they are, but how did you get the reflections from all angles so perfect? Is that some form of path tracing?

How did you get the shadows of out of scene spheres to perfect cast in the reflections on the metal spheres?

Lastly, are you going to release this as a demo we can run? Is this something you are going to sell?
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 28th Oct 2019 00:30 Edited at: 28th Oct 2019 00:36
It's just an early test for some hybrid rendering I need for a project. Yes, there is pathtracing being used.
I plan on writing a tutorial series on these kind of things once the work stress dies down. It's really fun to play around with and AppGameKit can handle it beautifully.
Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 28th Oct 2019 00:35
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 28th Oct 2019 00:40 Edited at: 28th Oct 2019 00:57
Yes, same approach. It's a great trick when you need a high amount of the same objects.
My test was basically to see how far I can push quality while staying at fluid framerates on my midrange rig (I have a GTX1070).
Luckily it's fast enough to be used for what I plan to do
Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 28th Oct 2019 00:58
I often wondered.....in AppGameKit you can instance an object, but it does nothing - pressumably because you then need the GPU side code to draw the instances objects. I keep meaning to play with it and see if instancing an object in AppGameKit is set up to let a shader then pick up the work load. Have you tried that?
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 28th Oct 2019 02:35 Edited at: 28th Oct 2019 03:03
A really interesting topic for sure.
It does actually seem to work. Without custom shader code too, you just don't necessarily get a noticeable speed boost from it unless pushing a LOT of geometry.
You will most likely not see a speed difference until you reach a certain threshold, which depends on several factors. As an example, if your game is GPU bound (most likely due to being fillrate limited), instancing won't do much.

The key difference is that you only have one copy of the geometry data.
Object position, rotation and scaling are just transformations and not in the actual object data, so placing the instances around is not a problem. Those transformations will be applied in the vertex shader anyway, even in stock rendering. (it's the object space to world space conversion in the vertex shader)

Quickly tested it with loading mid polycount sphere models, somewhere around 2000 of them I start seeing a difference in performance between unique meshes and instances. Stock rendering, nothing fancy. Just loadobject vs instanceobject.
The FPS impact is not huge though. 15 to 20% maybe. But there are a lot of factors involved, so it may be quite different on other systems and with other geometry.

There is also the advantage of the instanced method loading them instantly while actually loading 1000s of Obj meshes takes a few sec

And lower memory usage is a HUGE advantage too. (CPU memory)
With 8000 spheres: 50MB vs. 950MB.
16000 spheres: 60MB vs 1.8Gigs.
That's quite significant when building huge game worlds. For that reason alone it's worth it to use instancing if applicable, even if the direct FPS impact is not always a big deal.
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 28th Oct 2019 21:45
After seeing this beauty my only question is: why we mortals don't have access to pbr shaders in AppGameKit?
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 28th Oct 2019 22:38
To be fair, PBR is not about the shaders, but much more about all the lighting data you need to generate.
It's much easier to implement in an engine with an editor based workflow, where all the setup and eventual precalcs can be done there internally. They'd also need to add some rendering features that might be an issue on some export targets. Tons of little things need to be ironed out.
I am sure they will come up with a good solution, maybe helper functions or a simple editor for lighting setups. Until then it's "roll up the sleeves mode" unfortunately.
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 28th Oct 2019 23:01
Quote: "Until then it's "roll up the sleeves mode" unfortunately."


I was afraid of reading that. I don't see any info from developers regarding anything you mention above, we got Vulkan and the situation is turned into: ok, now what. My hands are tied, I choose this engine because of its simplicity, but, I can't have pbr, some proper shaders packed with engine, environment probes, even bloom fx for lighting, and list goes on and on and on, which are just basic rendering options for today's standards. Not to mention 3D placement editor is still mising.

Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 29th Oct 2019 11:43
Psychoanima, what is it you want PBR for? The world became slightly obsessed with this, but theres not that many AAA titles even use it extensively yet. From what I understand, PBR essentially let's you take a model and put it into various lighting conditions and still look good with minimal extra work, wheres as with more traditional methods putting a model in, say, a wet environment might mean a new set of textures.

If you had a PBR shader built into AppGameKit, youd still need to generate the six textures stages it needs (like the normal shader still needs a normal map), and just turning that on will not suddenly make your game world have perfect reflections.

I often wonder if theres often misconception of the difference between PBR and ray tracing.
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 29th Oct 2019 18:27
Differences between raytracing and pbr are huge, rendering is done completely different. That said, raytracing is hardware killer (rendering on fly) while pbr can be run on midrange computers (you can think of it as pre-render image)

In terms of pbr shaders, just take a look of substance designer software, how easily you can export textures for it, it will really spark your imagination what it can be done with this techinque/technology.

janbo
11
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 29th Oct 2019 20:19 Edited at: 29th Oct 2019 20:20
Quote: "To be fair, PBR is not about the shaders, but much more about all the lighting data you need to generate.
It's much easier to implement in an engine with an editor based workflow, where all the setup and eventual precalcs can be done there internally."

Exactly !
Gabor not only knows how to create the system for Physically Based Lighting, but seems to be a talented designer also and probably has his workflow ironed out.
Then creating a whole game that meets the expectations of todays gamers if they see PBR and having a consequent art style,
doing this without a proper toolchain, just would be a daunting task.
With all politeness and without trying to treat someone as a child, If you really just want a PBR shader I can give you one.
You now have access to Vulkan...yes ...TGC has to begin somwhere.

AGK is no Unity or Unreal(not for now) until then they have enough work to do.
Thats my opinion.
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 29th Oct 2019 21:42
Janbo, pbr shader is just a tip of an iceberg, there is so many shaders missing that I could do a very big list of them and you can tell if they are essential or not:

for models (static and animated):
diffuse
diffuse + alphamask
diffuse + normal
diffuse + normal + alphamask
diffuse+normal+specular
diffuse+normal+specular+alphamask
diffuse+normal+specular+emission
diffuse+normal+specular+env
shadow+animation+alphamask
multi layer texture (up to 7 texture slots with ability to apply bone animation)
pbr...
leaves (warp)

lights:
pointlightvolume
probe
spotlight
spotlightvolume


postfx:
a lot of them...
janbo
11
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 30th Oct 2019 12:29 Edited at: 30th Oct 2019 12:31
Well, what should TGC do in your opinion ? Create commands that apply those effect for all possible combinations ?
It is possible to generate those combinations for sure but i think thats up to the game developer here as there will be a shader that you dont have a combination for. My shader pack for example covers alot of different techniques which have nothing to do with PBR.
diffuse+normal+specular is in there and the dissolve shader might be what you revere by diffuse + alphamask.
Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 30th Oct 2019 12:49
It's a very key point: AppGameKit is a coding language.....it requires coding. I myself knew nothing about shaders, or C in general, before I started playing with it using some net examples about 18 months ago. Now, I'm far from Janbo or Garbor, but I can follow most shaders and write most effects to some degree.

That was my point about pbr....agk added a normal mapping command, but you still need to create the media. And if you needs it tweaked, for different lighting for example? What then?

And lastly.....who is going to have the resources to use AppGameKit to do a full PBR project? Lol.
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 30th Oct 2019 18:22 Edited at: 30th Oct 2019 18:23
Quote: "Well, what should TGC do in your opinion ? Create commands that apply those effect for all possible combinations ?"


I think that shaders in AppGameKit should be simplified the way many commands are already. To blend two animation sequences for rigged 3d object in AppGameKit I don't need to do calculus and fight with vectors for each bone, I give one command with two arguments: blend this animation sequence with this one - end of story. Why we can't have simplified commands like this for shaders? We can have variety of shaders sorted by id's, same way we have tween id's (from 0-8) for linear , ease in, ease out... (in this case 1 for diffuse, 2 for metallic, etc.)


Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 30th Oct 2019 19:45
So basically TGC should pre code every possible shader type and combination?????

Would be interesting when two had to interact....
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 30th Oct 2019 20:24
@psychoanima
While that's certainly an approach for stylized rendering and special effects, I feel it's the opposite direction of where the systems should be heading.
For semi-realistic rendering (including PBR), you can't freely mix and match components or shader code blocks. Because there is only one physically correct way of combining the components.

In my opinion the goal should be to keep it completely data driven (texture and uniform settings driven), but have one main shader codebase. The system could ofcourse still create permutations based on the material's setup to keep things performant, but in general users shouldn't need to touch or control any code.
That's the beauty of an approach like PBR, it's data driven but can display any real world material realistically just based on the input textures and settings. (things like "add clearcoat layer" could be uniform settings.)

Just to play devil's advocate...imagine using the suggested "mix it all at will" system and letting users control the mixing of components directly. How long until someone mixes diffuse lighting into their pure metal surface's reflections and then complains loudly that it doesn't look correctly metallic and the rendering sucks. Well, ofcourse it doesn't look realistic, they mixed together a material that doesn't exist.

For now janbo's shader pack should cover most of your needs with ease. He has a great selection of quality effects and styles.
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 30th Oct 2019 21:20 Edited at: 30th Oct 2019 21:22
Quote: "imagine using the suggested "mix it all at will" system and letting users control the mixing of components directly. How long until someone mixes diffuse lighting into their pure metal surface's reflections and then complains loudly that it doesn't look correctly metallic and the rendering sucks. "


I absolutely agree with you, but what if we have integrated shaders inside AppGameKit called like names of materials, Glass, Metal, Plastic? Each material would ask different type of texture for certain "layer" and if users mess things up, well, read the manual


What I wanted to ask you GaborD, since you are really amazing in what you are doing with shaders, how hard would be to get one "material" in AppGameKit that has following:


Diffuse
attributes: texture/ color value, brightness value

Normal
attributes: texture, normal value

Roughness
attributes: texture, roughness value (from rough to glossy)

Metallic
attributes: texture, metallic amount

Specular
attributes: texture/color value, brightness value, fresnel amount

Reflection
attributes: dds cubemap, exposure level



This material would basically be universal, by moving the values we could simulate attributes of stone, glass, aluminum and other goodies.
PSY
Valued Member
3
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 30th Oct 2019 22:10
Quote: "I plan on writing a tutorial series on these kind of things once the work stress dies down."


Man, that would be really really awesome


PSY LABS Games
Coders don't die, they just gosub without return
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 31st Oct 2019 00:59 Edited at: 31st Oct 2019 01:24
Quote: "but what if we have integrated shaders inside AppGameKit called like names of materials, Glass, Metal, Plastic? Each material would ask different type of texture for certain "layer" and if users mess things up, well, read the manual"


Yes, that sounds like a good approach. They could be based on a physically correct PBRish core and basically be shortcuts for achieving the looks of those materials without needing to tweak everything manually. I like the idea, makes it easier for users to get to the correct parameter settings.


Quote: "how hard would be to get one "material" in AppGameKit that has following:
Diffuse, attributes: texture/ color value, brightness value
Normal, attributes: texture, normal value
Roughness, attributes: texture, roughness value (from rough to glossy)
Metallic, attributes: texture, metallic amount
Specular, attributes: texture/color value, brightness value, fresnel amount
Reflection, attributes: dds cubemap, exposure level"


Right now, when aiming for general usage, quite hard. Not the material itself, the shader part is easy, but the rest.
Getting all the data it needs to look right is currently the hard part. Especially if you are aiming for a system any user could use without hassle, outside tools, custom converters, etc.

Roughness and Reflections work in tandem and are where the real issues start. They only work if you have correctly convoluted HDR reflection probes or an other solution to generate all the high range reflection data for any roughness value. AppGameKit has no floating point textures, no DDS cubemap support, no internal way of generating the data. You have to currently find workarounds for all of that.
The thing to keep in mind is that PBR lives or dies with it's reflections. They are the defining factor. The diffuse is just stock oldschool lambertian usually, like 20 years ago. What makes PBR special is adding correct reflections on top, we have to get those right. Especially for metals. They don't have diffuse, so their basic formula is: finalColor = reflections.

Diffuse and Normal we already have, even in stock rendering, so that's easy for realtime lights, just have to make sure it's not clamped to LDR (I never tested stock lighting in this regard).
If you use lightmaps, same issue as with reflection probes, you need HDR data.

Specular is not really a thing that we need to waste texture slots on if we have a metalness channel. You can kinda scratch that one off the list.
Basically, either you go metalness-roughness route and don't need specular channels or you go specular-gloss style and don't need metalness. I prefer the metal-rough workflow, but both work fine.

You can ofcourse solve all of the issues, but it will be a very specific solution for your workflow and there are also tiny tidbits you have to find solutions for. (Example: Some approaches HDR to RGBA packing having issues with bilinear filtering)
psychoanima
1
Years of Service
User Offline
Joined: 19th Jun 2018
Location:
Posted: 31st Oct 2019 08:42
Thanks for explaining that and pointing on some important issues regarding pbr creation in agk. It remains the hope that agk will get in near future support for those formats and data generation. Maybe if they start first with probe lighting, don't know...

janbo
11
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 31st Oct 2019 18:43 Edited at: 31st Oct 2019 18:52
I love finally talking obut that kind of stuff was uncertain all the years, but turns out I'm not that far off.

You can write an Uber shader but it would also cost you uber performance except you have a alot of branching, which again isn't the best idea for something that likes to execute stuff in paralell.
Then there is also the method to generate the shader code like TGC already does for a few things, which I really like, but then you'll have to be carefull with the different combinations again.
There is a reason why Unity and Unreal have visual shader editors I guess.

Quote: "AppGameKit has no floating point textures, no DDS cubemap support, no internal way of generating the data. You have to currently find workarounds for all of that"

I have cube and dualparabolic mapping for environment stuff working.
GaborD
2
Years of Service
User Offline
Joined: 3rd Dec 2017
Location:
Posted: 31st Oct 2019 19:05 Edited at: 31st Oct 2019 19:05
Yep, love these discussions. Always more to learn and to think about.
I agree on having to be careful with shader complexity and excessive branching. Can cost a lot of performance in some situations.
What I generally do is have an uber shader to keep development simple, but the individual parts then get assembled based on what is needed when it's compiled in order to get the correct lean permutations.

A visual shader editor could be a fun addition to AGK.
janbo
11
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 1st Nov 2019 14:39 Edited at: 1st Nov 2019 20:43
Quote: "but the individual parts then get assembled based on what is needed when it's compiled in order to get the correct lean permutations"

Thats basically what I meant by generating.

Quote: "A visual shader editor could be a fun addition to AGK."


I'd like to have GUI commands then I would have started one already.
Like to Code that stuff in AppGameKit (Tier 1) cause of WYSIWYG.
Rick Nasher
2
Years of Service
User Offline
Joined: 25th Jul 2017
Location: Amsterdam
Posted: 2nd Nov 2019 11:51
Quote: "A visual shader editor could be a fun addition to AGK."

+1
Santman
8
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 3rd Nov 2019 02:10
There's an extremely basic, very early shader visual editor if someone wants to continue it. All this does is scans a shader, then loads all the uniforms and sets them up on screen to be played around with.

Attachments

Login to view attachments

Login to post a reply

Server time is: 2020-01-19 17:01:32
Your offset time is: 2020-01-19 17:01:32