imbaczek wrote:jk: how hard would it be to have 2 separate exes with proper #ifdefs? we could provide a legacy binary and a present-tech binary if it's not hard to do.
jK wrote:and making Deferred Shading optional is too complicated.
To correct myself: it is nearly impossible.
But to repeat myself, first the render code needs a massive cleanup before such a step like Deferred Shading can be done.
So my current question is more this: Is it okay to drop asm shader support for a clean GLSL shader system? (-> no reflective units for intel users)
hoijui wrote:there was an other request, about 2 weeks or more ago, of someone that wanted spring in wireframe mode.
that would solve this issue as well, no?
Wireframe is even slower than polygon fill (driver internal reasons)
Also it is already in ...
imbaczek wrote:jk: how hard would it be to have 2 separate exes with proper #ifdefs? we could provide a legacy binary and a present-tech binary if it's not hard to do.
jK wrote:and making Deferred Shading optional is too complicated.
To correct myself: it is nearly impossible.
But to repeat myself, first the render code needs a massive cleanup before such a step like Deferred Shading can be done.
So my current question is more this: Is it okay to drop asm shader support for a clean GLSL shader system? (-> no reflective units for intel users)
+1
I think it would be OK as long as intel users still can run the game. If they want shaders, they should get a real gfx card.
imbaczek wrote:jk: how hard would it be to have 2 separate exes with proper #ifdefs? we could provide a legacy binary and a present-tech binary if it's not hard to do.
jK wrote:and making Deferred Shading optional is too complicated.
To correct myself: it is nearly impossible.
But to repeat myself, first the render code needs a massive cleanup before such a step like Deferred Shading can be done.
So my current question is more this: Is it okay to drop asm shader support for a clean GLSL shader system? (-> no reflective units for intel users)
+1
I think it would be OK as long as intel users still can run the game. If they want shaders, they should get a real gfx card.
Doesn't spring do frustum culling on the units? As in, not rendering units outside camera's view.
If spring does, then "put all into display list, draw shadow, draw direct" is not even an option. Would also be ton slower, because it'd have to put all units into list as opposed to just the visible ones, and because *construction* of display list is not a fast operation.
edit: as for deferred rendering, it is entirely different thing from what Argh talks about in original post.
Deferred rendering is: you render view as usual but using special shaders that rather than computing pixel colour directly, output just the parameters for calculation of pixel colour, into some huge buffer (=possible problems with video memory bandwidth). Then you render 1 quad on whole screen, passing buffer as "textures", and using pixelshader that computes pixel colour from those parameters.
This really doesn't seem to have anything to do with shadow rendering at all, and optimization of latter in particular.
Last edited by dizekat on 02 Nov 2008, 18:26, edited 1 time in total.
The whole idea is flawed here in its implementation because building the display list is more slower than the current shadow code, and on top of that your effectively running the original code too. The overall cpu work done is changed from 1 to a value greater than 2, so it would be much slower. Then theres the destruction of the display list too to factor in.
Display lists give you a small speedup in exchange for an initial payoff, if you only use them one or two times, then you have a net loss of performance. What's more theyre primarily implemented via drivers on cpu end, and don't cache data in video ram as is normally thought.
As for that shadowmap comment:
We have 8 fingers and 2 thumbs. Now lets say we have a task called wiggle your finger, and we have to wiggle our finger then flip a counter which we'll call frame. Now if we wiggle 2 fingers, we'll have a high "framerate". If we up this to 4 fingers it wont get any faster because we have more than 4 fingers right? We can goto 8 and it'll just take the same amount of time, so using the same logic, we can assume we can wiggle as many fingers as we want each frame and it wont matter, itll be just as fast.
Now lets wiggle 1096 fingers. We only have 8 fingers but that'll be fine because our previous tests only showed that there is neglible differences between how many fingers we wiggle and how often we can do it. So go ahead and wiggle 1096 fingers using just your hands and tell me you can do it just as fast as doing it with 4.
jK wrote:But to repeat myself, first the render code needs a massive cleanup before such a step like Deferred Shading can be done.
So my current question is more this: Is it okay to drop asm shader support for a clean GLSL shader system? (-> no reflective units for intel users)
Intel users don't have any business running any kind of high quality options anyway, so +1 as long the game works.
I am not in favor of changing Spring to make it harder to do Unit shaders. We're about to the point where, if UnitTBN was implemented, we'd be at a point of complete freedom to define our own per-unit shaders... why would we want to step backwards, and as jK put it, put 95% of the GLSL people out of the loop?
Given how few of us there actually are... we're talking 1, maybe 2 people. That's not a good plan- if anything, we need to make this something that's more easily accessible to people at all skill levels. Unit shaders should, ideally, be something an artist picks out, or designs with tools like Mental Mill... and then sticks into some standard code- taking it even further into the realm of hardcore-coders-only is a very bad plan.
I can't support that, as proposed.
Now, before everybody thinks I'm being overly negative, or am just trying to give jK a hard time, given that he's volunteering to try climbing one of the last remaining mountains... I'd be all for it... if we have a tag where we define which properly-formatted GLSL shader we used for the Unit at runtime (and writing said shader requires knowledge of GLSL and reading the documentation).
That seems like a good compromise- if somebody wants to do a custom specmap implementation, try stencil-buffer shadows, do a reliefmap that changes in realtime, etc., etc., that's all just fine, they just need to read directions, ask a few stupid questions, and implement it in GLSL.
But we don't want an elite.
We've had that situation for over a year now, because GLSL--> Lua hasn't been explained very well by anybody and documentation is practically nonexistent, and if anything, it's stifled progress. You can't build an advanced uber-Spring on the basis of jK gradually writing more Unit shaders and putting them into CA without documentation, or on the basis of Zpock's unreleased experiments, etc.
We should instead create a situation where people write GLSL shader implementations and make them available either freely or under GPL... and people who can't do that can still plug them in to their work as game designers, by reading some directions. Otherwise we'll end up with an elite, whose projects are visually so much more advanced than anything else that it will be ridiculous.
The situation is already trending that way- I sat down to learn GLSL in large part because I have some inclination to democratize it by releasing any shader work I do, to even up the playing field a bit.
Per-unit Shaders are one of the long-term biggies, and we shouldn't lose sight of that in exchange for better speed in the short term. As much as I like starting brainstorming sessions like this, that's not a desirable outcome- when in doubt, we need to structure for freedom for the folks creating the final content, even if that costs some speed.
At any rate... all of that said... I'm going to try to implement a stencil-buffer shadowmap, just for Units (like BlobShadows, basically, but using a shader, not a blob on a quad). I'm still reading through GPU Gems, I'll get back to y'all about that- it may turn out to be cheaper and faster to implement it the way I'm thinking about than to do a total overhaul of the system (although it will have certain limitations, since it will not permit the world to cast shadows).
Meh, I've been reading about shadows for hours, and I'm getting pissed off. Most of the things I need to have, to implement either volume shadows or a shadowmap are not available in Spring's current Lua-->OpenGL interface.
Things like more than one viewport, proper access to Unit geometry instead of the hack-around that is gl.Unit, etc., etc. A lot of this is just missing functionality, period, not stuff you can really work around. I'm pretty grumpy at this point- I don't mind a hackish solution if nothing better is available, but we can't, for example, do depth testing, unless I'm missing something obvious (quite possible, I've been reading dozens of articles and I'm tired and grumpy, and we all know I'm not the sharpest tool in the shed- maybe there's an obvious solution sitting under a digital rock somewhere).
I seem to remember somebody around here saying that it was possible to render something to a texture... I can't seem to find that anywhere. It'd at least provide a hackish workaround, if I could render objects from the sunangle off-screen somewhere, store it as a texture, and then just apply it to a quad and distort it. Slower than hell to do it that way, though- I want proper volume shadows, and that requires access to the scene as a whole- access to a lot of data that Spring does not deliver
Argh wrote:Meh, I've been reading about shadows for hours, and I'm getting pissed off. Most of the things I need to have, to implement either volume shadows or a shadowmap are not available in Spring's current Lua-->OpenGL interface.
Things like more than one viewport, proper access to Unit geometry instead of the hack-around that is gl.Unit, etc., etc. A lot of this is just missing functionality, period, not stuff you can really work around. I'm pretty grumpy at this point- I don't mind a hackish solution if nothing better is available, but we can't, for example, do depth testing, unless I'm missing something obvious (quite possible, I've been reading dozens of articles and I'm tired and grumpy, and we all know I'm not the sharpest tool in the shed- maybe there's an obvious solution sitting under a digital rock somewhere).
I seem to remember somebody around here saying that it was possible to render something to a texture... I can't seem to find that anywhere. It'd at least provide a hackish workaround, if I could render objects from the sunangle off-screen somewhere, store it as a texture, and then just apply it to a quad and distort it. Slower than hell to do it that way, though- I want proper volume shadows, and that requires access to the scene as a whole- access to a lot of data that Spring does not deliver
Wouldn't this mean that an engine implementation should be more appropriated ?
Ah. Cool, at least I'm not at a complete dead-end, then. I'll take a look at that after finishing some basic real-time lighting stuff for that little project then.
(driver internal reasons)
