custom shaders versus inbuilt shaders

[Shadowfury333]

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.

[gajop]

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.

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.

[Kloot]

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...

[Shadowfury333]

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.

(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.

[Silentwings]

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.

[Shadowfury333]

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.

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.

[zwzsg]

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.

[Shadowfury333]

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.

[Kloot]

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.

[smoth]

(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.



Imma go cry in a corner.

[hokomoko]

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.

[smoth]

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

[Shadowfury333]

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.

[Silentwings]

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.

[gajop]

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).

[Silentwings]

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.

[Kloot]

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.

[Shadowfury333]

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.

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.

[Karl]

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.