custom shaders versus inbuilt shaders
Moderator: Moderators
- Shadowfury333
- Posts: 55
- Joined: 25 Sep 2006, 00:32
custom shaders versus inbuilt shaders
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.
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.
Re: New gl.UnitShape is less useful
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.
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.
ForceShaders=1 and hope for the best.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.
Re: New gl.UnitShape is less useful
This paragraph still betrays a lack of insight.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.
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.)
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...I guess this means legacy support for computers that can't handle shaders properly pretty much has to be dropped.
- Shadowfury333
- Posts: 55
- Joined: 25 Sep 2006, 00:32
Re: New gl.UnitShape is less useful
I guess, but I'm not sure how much Lua code has cross-pollinated. Chili is a good example, I guess.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.
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.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...
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
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: custom shaders versus inbuilt shaders
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.I'm not sure how much Lua code has cross-pollinated
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
- Posts: 55
- Joined: 25 Sep 2006, 00:32
Re: custom shaders versus inbuilt shaders
Fair enough.Silentwings wrote: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.I'm not sure how much Lua code has cross-pollinated
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.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.
Re: custom shaders versus inbuilt shaders
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
- Posts: 55
- Joined: 25 Sep 2006, 00:32
Re: custom shaders versus inbuilt shaders
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.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.
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.
Re: custom shaders versus inbuilt shaders
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.
It's really no different than development for engines like Unity, just with a lower baseline.
Re: New gl.UnitShape is less useful
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.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...
Imma go cry in a corner.
Re: custom shaders versus inbuilt shaders
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.
Shaders in public repositories are easier to remember.
Re: custom shaders versus inbuilt shaders
It has been getting updates for 4 years... just saying.
- Shadowfury333
- Posts: 55
- Joined: 25 Sep 2006, 00:32
Re: custom shaders versus inbuilt shaders
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.smoth wrote:It has been getting updates for 4 years... just saying.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: custom shaders versus inbuilt shaders
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.The biggest hurdle now that legacy shaderless support seems to be forced out the window
Re: custom shaders versus inbuilt shaders
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).
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
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: custom shaders versus inbuilt shaders
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.
Re: custom shaders versus inbuilt shaders
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.maybe something like the PBR is the way to go
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.the current custom shaders being too slow because of all the lua callouts/callins overhead they have
- Shadowfury333
- Posts: 55
- Joined: 25 Sep 2006, 00:32
Re: custom shaders versus inbuilt shaders
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.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.
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.
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.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.
Re: New gl.UnitShape is less useful
I'd assume it's due to the 1% Rule.smoth wrote:mostly this just makes me sad. No matter what I do around here I am forgotten.