custom shaders versus inbuilt shaders

custom shaders versus inbuilt shaders

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Post Reply
User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

custom shaders versus inbuilt shaders

Post by Shadowfury333 » 12 Feb 2016, 04:05

Split from viewtopic.php?f=12&t=34401&p=575791#p575754 (Silentwings)

The issue is not complexity, it's in not repeating oneself. Having a bool that basically says "use the basecontent shader" would keep it simple in simple cases while allowing complex cases to be handled in-place, and let changes to the basecontent shaders be automatically propagated to these simple cases without every game dev constantly copy-pasting from the spring repository.

I guess this means legacy support for computers that can't handle shaders properly pretty much has to be dropped. I'm mostly excited about that, since I've felt really held back by that limitation, but I'm also worried hardly anyone will be able to play.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: New gl.UnitShape is less useful

Post by gajop » 12 Feb 2016, 04:43

Shadowfury333 wrote:The issue is not complexity, it's in not repeating oneself. Having a bool that basically says "use the basecontent shader" would keep it simple in simple cases while allowing complex cases to be handled in-place, and let changes to the basecontent shaders be automatically propagated to these simple cases without every game dev constantly copy-pasting from the spring repository.
Maybe not a "bool", but is there a basecontent shader file we could use from Lua? That seems reasonable.
The one I provided here has some rendering discrepancies.

Actually I think we may be better of with some sort of extension to the Custom Unit Shader Framework for unitDefs, as well as a new Custom Map Shader Framework for the 101+ map shader support.
Shadowfury333 wrote:I guess this means legacy support for computers that can't handle shaders properly pretty much has to be dropped. I'm mostly excited about that, since I've felt really held back by that limitation, but I'm also worried hardly anyone will be able to play.
ForceShaders=1 and hope for the best.
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: New gl.UnitShape is less useful

Post by Kloot » 12 Feb 2016, 12:48

The issue is not complexity, it's in not repeating oneself. Having a bool that basically says "use the basecontent shader" would keep it simple in simple cases while allowing complex cases to be handled in-place, and let changes to the basecontent shaders be automatically propagated to these simple cases without every game dev constantly copy-pasting from the spring repository.
This paragraph still betrays a lack of insight.

The idea is *not* to provide over 9000 different knobs for the standard shaders (which are inherently limited and someone will always find one missing, even if the common case is just "draw crap with a tint"), but rather for games to move away from them by building up their own libraries of more advanced interchangable shader effects, similar to how general Lua code has cross-pollinated.

(Not that I'm getting my hopes up: with the exception of BAR nothing beyond basic normal-mapping has appeared after 8 years of CustomUnitShaders and all of trepan's hints / incentives before it, so you can guess how far Spring is graphically behind a typical AAA title now.)
I guess this means legacy support for computers that can't handle shaders properly pretty much has to be dropped.
That should have happened a long time ago, but for some reason people keep thinking / expecting they should be able to run a 3D game engine on obsolete / inadequate hardware because "it's FOSS" or "Intel is good enough". You're not the only party being held back here...
0 x

User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

Re: New gl.UnitShape is less useful

Post by Shadowfury333 » 13 Feb 2016, 06:46

Kloot wrote:The idea is *not* to provide over 9000 different knobs for the standard shaders (which are inherently limited and someone will always find one missing, even if the common case is just "draw crap with a tint"), but rather for games to move away from them by building up their own libraries of more advanced interchangable shader effects, similar to how general Lua code has cross-pollinated.
I guess, but I'm not sure how much Lua code has cross-pollinated. Chili is a good example, I guess.
Kloot wrote:(Not that I'm getting my hopes up: with the exception of BAR nothing beyond basic normal-mapping has appeared after 8 years of CustomUnitShaders and all of trepan's hints / incentives before it, so you can guess how far Spring is graphically behind a typical AAA title now.)

That should have happened a long time ago, but for some reason people keep thinking / expecting they should be able to run a 3D game engine on obsolete / inadequate hardware because "it's FOSS" or "Intel is good enough". You're not the only party being held back here...
These are kinda related. Having to maintain legacy support means limits to what can be pushed without having to have two render paths for everything, and since this is mostly hobby development, there usually isn't time to maintain both legacy and modern render paths. My job is in industry (Naval Architecture tools) and the company only shifted to OpenGL 3.2 (i.e 6+ year old tech) when I joined about 3 years ago, because the client base would likely have machines capable of using it. Even then I've had to write some 2.1 fallback support into the engine.

Also, wouldn't the BAR people flip out if others were grabbing their shaders before it released? Because that's the impression I've gotten. That being said, I'd rather push Zero-K towards a more western 2d animated look, since that would likely age better and look better with the relatively uniform textures a lot of units have (ex. gunships, hovercrafts, caretakers). Still requires proper shader support to make that work, mind you, just not in the AAA photo-realistic way.
0 x

User avatar
Silentwings
Moderator
Posts: 3597
Joined: 25 Oct 2008, 00:23

Re: custom shaders versus inbuilt shaders

Post by Silentwings » 13 Feb 2016, 11:11

I'm not sure how much Lua code has cross-pollinated
It's harder to find any that hasn't. If you're not aware of this, I don't think you're in much position to judge the likely future of whether or not games will build on each others shaders.

One point that's been missing here; in the past I felt like I had to avoid shaders in lua code when possible because it ~always didn't work for ATI in some way (and I had an old machine which ~always didn't work whenever I tried). This seems to no longer be a problem.
0 x

User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

Re: custom shaders versus inbuilt shaders

Post by Shadowfury333 » 13 Feb 2016, 19:57

Silentwings wrote:
I'm not sure how much Lua code has cross-pollinated
It's harder to find any that hasn't. If you're not aware of this, I don't think you're in much position to judge the likely future of whether or not games will build on each others shaders.
Fair enough.
Silentwings wrote:One point that's been missing here; in the past I felt like I had to avoid shaders in lua code when possible because it ~always didn't work for ATI in some way (and I had an old machine which ~always didn't work whenever I tried). This seems to no longer be a problem.
Oh right, ATI issues. Well, if those are out of the way too, I'm super excited. I realize I didn't come off like it earlier, but I am.
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7017
Joined: 16 Nov 2004, 13:08

Re: custom shaders versus inbuilt shaders

Post by zwzsg » 14 Feb 2016, 00:43

My point was more that I see Spring as mean to enable people who can't or don't want to write their own engine to still be able to make their RTS game. If you let the simple interfaces die and require modders/game makers to write shader code, then it loses its appeal.
0 x

User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

Re: custom shaders versus inbuilt shaders

Post by Shadowfury333 » 14 Feb 2016, 05:48

zwzsg wrote:My point was more that I see Spring as mean to enable people who can't or don't want to write their own engine to still be able to make their RTS game. If you let the simple interfaces die and require modders/game makers to write shader code, then it loses its appeal.
Existing game makers will more than likely make an API widget/include-able Lua file to simplify the simple cases. Gajop was already talking about it, I intend to do it at some point for Zero-K, and it's generally good practice in general to factor out repeated stuff into its own functions and libraries.

Once those are done, game makers who don't want to write their own shader code can just grab one of those libraries and use those shaders.
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: custom shaders versus inbuilt shaders

Post by Kloot » 14 Feb 2016, 12:53

Shaders are also de-facto "required" already, in the "how to make your game visually appealing in 2016 to a wider (non-*A) audience" sense. Nicer models and textures only form part of the equation.

It's really no different than development for engines like Unity, just with a lower baseline.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: New gl.UnitShape is less useful

Post by smoth » 15 Feb 2016, 00:57

Kloot wrote: (Not that I'm getting my hopes up: with the exception of BAR nothing beyond basic normal-mapping has appeared after 8 years of CustomUnitShaders and all of trepan's hints / incentives before it...
It isn't like I have a thread from 2012 where I have been working on this sort of thing... but mostly this just makes me sad. No matter what I do around here I am forgotten.

Image

Imma go cry in a corner.
0 x

hokomoko
Spring Developer
Posts: 585
Joined: 02 Jun 2014, 00:46

Re: custom shaders versus inbuilt shaders

Post by hokomoko » 15 Feb 2016, 01:23

Well, part of the reason is that it's only in your thread (as far as I'm aware).

Shaders in public repositories are easier to remember.
0 x

User avatar
smoth
Posts: 22300
Joined: 13 Jan 2005, 00:46

Re: custom shaders versus inbuilt shaders

Post by smoth » 15 Feb 2016, 07:20

It has been getting updates for 4 years... just saying.
0 x

User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

Re: custom shaders versus inbuilt shaders

Post by Shadowfury333 » 16 Feb 2016, 08:37

smoth wrote:It has been getting updates for 4 years... just saying.
Thanks, that will save time. The biggest hurdle now that legacy shaderless support seems to be forced out the window by the engine will be to catch up on shaders for materials and effects. I'm more concerned about effects myself, since materials are a more involved (both shader code and textures) and less game-general element (each unit with its own textures vs. every build effect, building placement effect, ghost-site location, etc. being made snazzy with one file change each), but both are necessary.
0 x

User avatar
Silentwings
Moderator
Posts: 3597
Joined: 25 Oct 2008, 00:23

Re: custom shaders versus inbuilt shaders

Post by Silentwings » 16 Feb 2016, 10:02

The biggest hurdle now that legacy shaderless support seems to be forced out the window
No, it remains possible to make games for Spring without touching shaders, and there is no sign of that changing. The issue only arises when a game wants to add relatively special visual effects, beyond lups and cegs.
0 x

gajop
Moderator
Posts: 3023
Joined: 05 Aug 2009, 20:42

Re: custom shaders versus inbuilt shaders

Post by gajop » 18 Feb 2016, 12:05

I'm not exactly that well informed about shaders, but I've noticed some engines (e.g. Unity) have adopted the approach of Physical Based Rendering (PBR), which essentially means using "one shader" with a bunch of common effects in place to present nearly all natural objects.
I like the ability to make custom shaders, but maybe something like the PBR is the way to go for most use cases?

Also, I think there was some mention about the current custom shaders being too slow because of all the lua callouts/callins overhead they have. I haven't tested it myself empirically but I can certainly see how that would be so and I think I did get similar results in Flove (applying the tree shader to flowers would cause a noticeable FPS drop).
0 x

User avatar
Silentwings
Moderator
Posts: 3597
Joined: 25 Oct 2008, 00:23

Re: custom shaders versus inbuilt shaders

Post by Silentwings » 18 Feb 2016, 12:40

I think there is a more general long term worry with using gl from lua, in that we don't have a good way to profile how much it costs. Probably many people don't realize that the widget/gadget profilers include the time spent by lua to send the gl calls off, but don't include the cost of actually carrying them out - and this leads people to think they cost almost nothing and blame slowdown on the engine.
0 x

Kloot
Spring Developer
Posts: 1865
Joined: 08 Oct 2006, 16:58

Re: custom shaders versus inbuilt shaders

Post by Kloot » 18 Feb 2016, 14:04

maybe something like the PBR is the way to go
Part of viewtopic.php?p=574231#p574231, would fall into the "rewrite everything" category. Custom PBR shaders however can be realized in 101 (warning: this is not beginner-level material) if you feel like experimenting.
the current custom shaders being too slow because of all the lua callouts/callins overhead they have
The per-object Draw{Unit,Feature} callins (which are *not* intended to be enabled permanently, just for setting the occasional batch of uniform values) can kill performance, yes. {Unit,Feature}Rendering shaders themselves don't have much overhead.
0 x

User avatar
Shadowfury333
Posts: 55
Joined: 25 Sep 2006, 00:32

Re: custom shaders versus inbuilt shaders

Post by Shadowfury333 » 19 Feb 2016, 05:52

gajop wrote:I'm not exactly that well informed about shaders, but I've noticed some engines (e.g. Unity) have adopted the approach of Physical Based Rendering (PBR), which essentially means using "one shader" with a bunch of common effects in place to present nearly all natural objects.
I like the ability to make custom shaders, but maybe something like the PBR is the way to go for most use cases.
Megashader approaches (not just for PBR) like that are an approach, but that's mainly really useful for materials shading, and AFAIK work best with Uniform Buffer Objects since you'll be adjusting behaviour by switching between different sets of uniform variable values, rather than by binding different shaders and redrawing objects.

However, for effects stuff, that's a trickier approach. For building an effects framework it would work, and would allow people to mix and match basic effects and interpolators and so forth to get what they want without diving into GLSL, but building such an effects framework is very much on the nice-to-have priority list. Having tiny shaders for each different effect is a more practical short-to-mid-term approach.

Kloot wrote:The per-object Draw{Unit,Feature} callins (which are *not* intended to be enabled permanently, just for setting the occasional batch of uniform values) can kill performance, yes. {Unit,Feature}Rendering shaders themselves don't have much overhead.
What about the gl.Unit() and gl.Feature() callouts? Are those also slow? If so I guess a megashader approach would make a lot more sense for long-term performance.
0 x

User avatar
Karl
Panzerstahl Developer
Posts: 746
Joined: 01 Apr 2010, 21:05

Re: New gl.UnitShape is less useful

Post by Karl » 29 Feb 2016, 23:27

smoth wrote:mostly this just makes me sad. No matter what I do around here I am forgotten.
I'd assume it's due to the 1% Rule.
0 x

Post Reply

Return to “Game Development”

cron